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ABSTRACT 


Implementation  of  modular  or  flexible  design  ships  has  introduced  gaps  in  the  United 
States  Navy’s  logistics  and  sustainment  operations  regarding  parts  support.  The  Navy’s 
supply  chain  management  system  must  consider  ship  weight  and  space  constraints, 
reduced  onboard  manning,  and  a  new  concept  of  shore-based  support  in  order  to  permit 
efficient  identification  and  assignment  of  spare  parts  to  multiple  distribution  and 
maintenance  locations  to  ensure  ship  mission  availability. 

Following  a  systems  engineering  management  process  the  team  identified  the 
problem,  relevant  stakeholders,  and  the  system  requirements.  An  analysis  of  alternatives 
was  conducted  on  existing  models  to  determine  which  one  could  be  suitable  for  altering 
to  meet  the  stakeholders’  requirements.  Modeling  and  simulation  was  used  to  simulate 
system  operations.  A  model  based  systems  engineering  approach  using  CORE  enabled 
requirements  management  and  traceability,  identification  of  system  functionality,  and 
development  of  system  diagrams  and  architectural  views. 

These  techniques  resulted  in  a  conceptual  and  partial  preliminary  design  of  the 
supply  chain  management  model.  This  model  addresses  the  need  for  a  parts  sparing 
system  in  support  of  modular  or  flexible  design  ships.  This  research  confirms  the  need  for 
such  a  model  and  the  project  output  provides  a  basis  for  continuation  of  system 
development. 
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EXECUTIVE  SUMMARY 


This  report  addresses  the  need  for  a  spare  parts  allocation  system  in  support  of  modular 
or  flexible  design  ships.  The  research  conducted  confirmed  the  need  for  the  supply  chain 
management  model  (SCMM)  system,  development  of  which  the  team  pursued,  and  the 
project’s  outputs  provide  a  basis  for  continuation  of  system  development.  The  team 
concluded  that  the  existing  Multi-Echelon  Readiness  Based  Sparing  (ME-RBS)  system  is 
the  best  alternative  suitable  for  adaptation  to  support  the  stakeholders’  needs  and 
requirements.  This  model  requires  additional  research  to  determine  whether  modification 
is  viable  in  terms  of  design  and  cost.  Another  option  is  the  development  of  a  new  system 
rather  than  adaptation  of  an  existing  system.  This  option  would  be  preferred  if  the  ME- 
RBS  system’s  design  could  not  be  altered  and/or  if  the  cost  were  above  that  of  new 
system  development.  Initial  cost  analysis,  based  on  assumptions,  indicates  that  adapting 
the  ME-RBS  system  would  be  less  costly  than  constructing  a  new  system.  The  team 
recommends  that  research  and  analysis  continue  in  support  of  the  development  of  the 
SCMM  system,  whether  it  is  the  alteration  of  the  ME-RBS  system  or  the  creation  of  a 
new  system,  to  meet  the  identified  stakeholders’  needs. 

The  systems/programs  currently  in  use  for  determining  spare  parts  allocation  do 
not  provide  information  that  takes  into  account  the  ability  to  modify  ships  rapidly  to 
introduce  warfare-specific  capability  through  the  use  of  mission  modules  nor  do  they  take 
into  account  shipboard  constraints  including  manning,  space,  and  weight  which  impact 
ships’  and  fleet’s  readiness  and  operational  availability,  based  on  the  team’s  research  and 
project  sponsor  input.  The  Navy’s  supply  chain  management  system  must  consider  these 
constraints  and  also  a  new  concept  of  shore-based  support  to  permit  efficient 
identification  and  assignment  of  spare  parts  to  multiple  distribution  and  maintenance 
locations  to  ensure  single  or  multi-ship  and  single  or  multi-mission  availability. 

To  determine  and  address  the  problem.  Team  RSRP’s  methodology  began  with 
identifying  team  member  roles  and  responsibilities  to  ensure  efficient  project 
development  coverage.  After  a  team  structure  was  established,  a  systems  engineering 
process  was  implemented  based  on  a  tailored  vee  model  that  included  the  following  main 


developmental  process  phases:  needs  analysis,  system  requirements,  system  architecture, 
conceptual  design,  modeling  and  simulation  (M&S),  system  integration  and  test, 
component  verification,  system  analysis,  and  system  validation. 

The  objective  of  the  needs  analysis  phase  was  to  understand  the  stakeholders’ 
needs,  wants,  and  desires,  to  further  develop  the  initial  problem  statement,  and  to  refine 
the  primitive  need  statement  into  an  effective  need  statement.  A  literature  review  was 
conducted  to  examine  the  material  related  to  supply  chain  management  (SCM)  for 
modular  or  flexible  design  ships,  and  to  discover  the  challenges  associated  with  it.  The 
problem  statement  was  then  finalized  as  follows:  As  the  U.S.  Navy  drives  toward  modular 
and  flexible  designs,  the  currently  used  surface  Navy  SCM  models  do  not  support 
modular  or  flexible  design  ships.  These  ships  require  an  off-ship  maintenance  support 
structure  consisting  of  multiple  logistics  and  repair  nodes  due  to  shipboard  constraints 
including  manning,  space,  and  weight. 

The  gap,  which  is  the  difference  between  the  current  state  of  the  system  and  how 
the  stakeholder  needs  the  system  to  perform  and  operate,  was  identified  as:  The 
systems/programs  currently  in  use  for  determining  spare  parts  allocations  do  not  provide 
information  that  takes  into  account  the  ability  to  modify  ships  rapidly  to  introduce 
warfare  specific  capability  through  the  use  of  mission  modules  nor  do  they  take  into 
account  shipboard  constraints  including  manning,  space,  and  weight  which  impact  ships  ’ 
and  fleet’s  readiness  and  operational  availability.  A  functional  analysis  was  performed 
next  to  identify  the  functions  of  the  system  through  the  utilization  of  use  case  scenarios. 

The  capabilities  of  the  system  were  identified  with  the  sponsor  at  this  time,  also. 
These  were  convert  (or  process)  data  inputs  into  information  to  be  used  for  providing 
spare  parts  at  various  locations  based  on  the  use  case  scenarios  and  allow  the  users  to 
conduct  sensitivity  analysis  based  on  the  inputs  for  trade-off  analysis  for  cost, 
operational  availability  (Ao),  personnel  requirements,  weight,  and/or  space,  both  derived 
from  the  need  statement.  Research  was  conducted  during  the  needs  analysis  phase  to 
include  stakeholder  “wants”  until  the  system’s  functions  were  identified.  The  top-level 
functions  of  the  system  were  determined  to  be  as  follows: 


•  Enable  graphic  user  interface 

•  Receive  data 

•  Process  data 

•  Provide  output 

•  Maintain  system 

•  Secure  system 

Once  the  problem  and  effective  need  statements  were  defined,  agreed  upon  by  the 
sponsor,  and  understood  by  the  stakeholders,  the  system  requirements  analysis  was 
conducted  based  on  the  Buede  method  for  requirements  analysis.  The  top  level  system 
requirement,  the  originating  requirement  for  the  SCMM  system,  is  the  need  statement: 
The  stakeholders  need  information  to  determine  sparing  of  parts  at  existing  and  multiple 
supply  points  in  order  to  support  the  Navy ’s  modular/flexible  ships  within  the  constraints 
of  manning,  space,  weight,  location,  and  cost/budget.  Input-output  analysis  was 
conducted  to  scope  and  bound  the  problem.  An  input,  control/constraint,  output,  and 
mechanism  (ICOM)  diagram  and  context  diagram  were  developed  as  a  result  of  these 
analyses.  Functional  and  non-functional  requirements  were  identified  from  the  system 
requirements  development  based  on  the  previously  conducted  functional  analysis  of  the 
system.  The  system’s  requirements  were  captured  in  Vitech’s  CORE,  a  systems 
engineering  and  project  management  toolset  that  was  used  to  trace  the  system 
requirements  to  stakeholder  needs,  document  system  functionality,  and  document  the 
system  architecture  (Vitech  2013). 

The  system  architecture  phase  was  used  to  capture  the  logical  sequencing  and 
interaction  of  system  functions  or  logical  elements.  The  system  architecture  was 
documented  using  CORE,  which  also  provided  a  model  based  systems  engineering 
(MBSE)  capability.  The  team  utilized  the  Department  of  Defense  Architecture 
Framework  v2.02  (DODAF)  to  define  the  different  architecture  views  of  the  system 
design.  Three  architectural  views,  capability  view  (CV),  operational  views  (OVs),  and 
system  views  (SVs),  were  created  to  show  the  relationship  of  inputs  and  outputs  and 
constraints  and  mechanisms  of  the  system  design.  The  output  of  this  phase  was  a  high 
level  system  design  and  a  generic  architecture  that  met  the  needs  of  the  stakeholders. 
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During  the  conceptual  design  phase  a  methodology  to  identify  a  system  design 
that  met  the  functional  and  performance  requirements  of  the  SCMM  system  was 
followed.  To  screen  established  and  operational  models  within  the  Department  of 
Defense  (DOD)  community  for  possible  adaptation,  Team  RSRP  used  weighted  criteria 
based  on  the  SCMM  system  requirements  to  conduct  an  analysis  of  alternatives  (AoA). 
Twenty-three  alternatives  were  generated,  and  the  three  highest  scoring  alternatives  were 
further  analyzed.  The  benefits  and  disadvantages  of  each  were  determined  resulting  in 
recommendation  of  a  model  for  further  investigation  and  possible  modification  to  fill  the 
Navy’s  supply  chain  gap. 

In  the  modeling  and  simulation  phase,  the  SCMM  system  and  the  current  system 
used  to  support  modular  and  flexible  design  ships  were  simulated  using  Imaginethat 
Inc.’s  ExtendSim  to  simulate  operations  and  determine  expected  system  performance 
versus  current  system  performance.  Microsoft  Excel  was  used  to  provide  a  proof  of 
concept  of  the  SCMM  system.  A  model  based  systems  engineering  approach  using 
CORE  enabled  requirements  management  and  traceability,  identification  of  system 
functionality,  and  development  of  system  diagrams  and  architectural  views.  These 
techniques  resulted  in  a  conceptual  and  partial  preliminary  design  of  the  SCMM  system. 

The  system  integration  and  test  phase  was  accomplished  concurrently  with  the 
M&S  phase  to  demonstrate  that  the  expected  system  performance  would  be  effective  and 
suitable.  A  test  plan  was  created,  and  level  one  and  level  two  testing  were  accomplished. 
Due  to  this  capstone  project’s  schedule  constraint,  the  design  was  not  mature  enough  to 
conduct  trade-off  studies  or  testing  to  ensure  readiness  and  maturity  of  the  system  design. 

In  the  integration  and  test  phase  the  intent  was  to  assemble,  integrate,  and  test  the 
system  elements  to  evaluate  its  design.  Performance  characteristics  were  to  be  verified 
and  the  design  issues  were  to  be  identified  to  the  stakeholders.  Trade-off  studies, 
including  readiness  and  maturity  of  the  system  design,  should  have  been  conducted.  Due 
to  this  capstone  project’s  schedule  constraint,  system  integration  and  test  did  not  include 
the  assembly,  integration,  and  test  of  the  system  elements,  but  did  include  system 
verification,  system  analysis,  and  system  validation  of  the  SCMM  system  simulation  that 
was  created  in  the  M&S  phase. 


Due  to  an  immature  design,  the  team  did  not  perform  the  component  verification 
phase  of  the  systems  engineering  process  (SEP).  This  phase  is  conducted  through  an 
effective  combination  of  analysis,  inspection,  demonstration,  and  testing  that  gauges  the 
maturity  of  each  component  of  the  design  (i.e.,  software  [SAV]  and  supportability)  prior 
to  integrating  the  overall  system  design  solution. 

In  the  system  analysis  phase,  design  alternatives  were  evaluated  during  the  AoA 
conducted  in  the  conceptual  design  phase;  cost  and  risk  analyses  were  also  performed. 
The  AoA  was  conducted  using  value  modeling,  based  on  a  weighted  chart,  and  with  a 
numerical  evaluation  matrix  to  determine  the  model  that  best  satisfied  the  stakeholders’ 
requirements.  Cost  analysis  was  conducted  using  the  constructive  systems  engineering 
cost  model  (COSYSMO),  a  model  used  to  help  assess  the  cost  and  schedule  implications 
of  systems  engineering  decisions.  COSYSMO  was  used  to  evaluate  the  different 
alternatives  that  resulted  from  the  AoA.  The  risk  analysis  focused  on  the  SCMM  system 
and  capstone  project  risks.  This  analysis  was  conducted  throughout  the  SEP  and  resulted 
in  the  development  of  the  Risk  Management  Plan  addressing  the  programmatic  and 
technical  risks  of  the  project  and  system.  The  output  of  the  system  analysis  phase  was  the 
identification  of  a  system  alternative  suitable  for  adaptation  to  support  the  stakeholders’ 
needs  and  requirements. 

The  last  phase  of  the  tailored  SEP,  system  validation,  ensures  that  the  as-designed 
system  meets  the  system  requirements  in  conformance  with  the  stakeholders’  needs 
(Blanchard  and  Eabrycky  2011).  This  process  also  demonstrates  that  the  designed  system 
achieves  its  intended  use  in  the  intended  operational  environment  (Blanchard  and 
Eabrycky  2011).  Although  this  phase  was  not  performed  in  its  entirety  due  to  the 
immaturity  of  the  system  design,  it  is  recommended  that  system  validation  continue 
throughout  the  design  of  the  SCMM  system  by  performing  progressive  and  iterative 
integrated  system  testing  to  validate  the  maturity  of  the  system  and  assess  overall  system 
readiness. 


XXV 


Team  RSRP  was  able  to  apply  a  tailored  SE  approach  to  define  and  conceptually 
design  a  solution  to  a  U.S.  Navy  supportability  problem.  It  is  hoped  that  additional 
research  supports  further  development  and  that  analyses  are  conducted  in  support  of 
finalizing  the  design  of  this  SCMM  system. 
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I.  INTRODUCTION 


Today,  the  United  States  (U.S.)  Navy  continues  to  be  the  world’s  most  powerful 
navy  when  considering  the  factors  of  size,  harnessed  technology,  and  the  geographical 
area  the  U.S.  Navy  covers  (Work  2008).  In  fiscal  year  2012,  $38,120,800,000  was 
enacted  to  support  the  sustainment  operations  of  the  many  different  classes  of  ships 
within  the  Navy  (Under  Secretary  of  Defense  [Comptroller]  2012).  According  to  the 
Under  Secretary  of  Defense  (Comptroller)  as  indicated  on  the  “Under  Secretary  of 
Defense  (Comptroller)”  website: 

The  Operation  and  Maintenance,  Navy  (OMN)  appropriation  finances  the 
day-to-day  costs  of  operating  naval  forces,  including  fuel,  supplies,  and 
maintenance  of  ships.  Navy  and  Marine  Corps  aircraft,  related  weapon 
systems,  and  the  support  establishment  ashore.  The  primary  focus  of  the 
Department’s  budget  is  to  continue  to  ensure  the  readiness  of  deployed 
forces.  (Under  Secretary  of  Defense  [Comptroller]  2012) 

The  supply  chain  personnel  are  responsible  for  overseeing  a  diverse  assortment  of 
goods,  material,  and  equipment  that  must  be  integrated,  transported,  and  maintained  to 
keep  the  Navy’s  ships  afloat  and  fully  operational.  The  supply  chain  that  is  used  to 
coordinate  the  parts  and  personnel  for  the  operations  and  sustainment  of  the  Navy’s  fleet 
is  extensive.  This  supply  chain  is  operated  and  supported  by  defense  contractors,  private 
industry  suppliers,  and  Department  of  Defense  (DOD)  supply  organizations  that  cover  the 
globe  with  sustainment  logistics  from  a  multitude  of  facilities  and  locations.  The 
geographical  breadth  in  which  the  Navy  operates  presents  a  major  challenge  with 
sustainment  activities  being  able  to  meet  operational  requirements  such  as  ship  mission 
availability,  maintenance  times,  and  personnel  support.  Logistics  and  sustainment 
operations  must  now  provide  support  to  modular  or  flexible  optimally-manned  classes  of 
ships  taking  into  account  weight,  space,  and  personnel  constraints  that  limit  parts  sparing 
methods  and  maintenance  actions  onboard  ships  while  taking  advantage  of  off-ship 
support  structures.  Parts  sparing  methods  use  models  that  are  in  current  use  to  determine 
which  parts  to  allocate  shipboard  in  order  to  support  a  ship’s  operational  availability 
requirement. 
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A.  OVERVIEW 

The  amount  of  material  required  to  support  a  ship  is  vast  and  varies  by  ship  class 
and  configuration  which  may  include  integrated  weapon  systems,  electronic  equipment 
for  communication  and  detection,  aircraft  support  and  additional  personnel  assigned  to 
the  ship  for  mission  support.  The  personnel  considerations  necessary  to  complete  the 
maintenance  actions  on  a  ship  require  training  and  planning  for  effective  support.  The 
majority  of  today’s  traditional  U.S.  Naval  ships’  supply  chains  rely  on  readiness  based 
sparing  (RBS)  to  supply  the  various  ship  classes.  According  to  the  Assistant  Secretary  of 
Defense,  as  described  on  the  “Supply  Chain  Integration”  webpage,  RBS 

...is  the  practice  of  using  advanced  analytics  to  set  spares  levels  and 
locations  to  maximize  system  readiness.  RBS  has  been  part  of  Department 
practice  since  the  1960s,  when  it  was  used  to  optimize  aircraft  availability, 
and  is  incorporated  into  DOD  Supply  Chain  Materiel  Management 
Regulation  (DOD  4140.1-R)  as  the  preferred  method  for  calculating 
inventory  levels.  (Assistant  Secretary  of  Defense,  Logistics  and  Materiel 
Readiness  2012) 

In  recent  years,  the  U.S.  Navy,  along  with  naval  forces  around  the  world,  has 
begun  to  plan  and  build  new  ship  classes  to  be  flexible  in  design,  resulting  in  each  ship 
having  modular  equipment  that  can  be  integrated  for  specific  mission  requirements.  The 
idea  of  being  able  to  switch  out  modular  equipment  has  come  to  the  forefront  with  regard 
to  ship  design  because  it  will  allow  a  specific  ship  to  be  able  to  support  many  different 
missions  with  varying  configurations  that  can  be  integrated  for  each  mission.  The  intent 
is  to  reduce  the  number  of  different  ship  classes  while  increasing  the  capabilities  of  each 
individual  ship  class.  However,  this  has  resulted  in  the  need  for  a  more  flexible  and 
responsive  supply  chain  to  support  the  sustainment  of  these  configurations  and  the 
supportability  and  maintenance  of  the  modular  mission  packages. 

Team  Right  Spare,  Right  Place  (RSRP)  has  developed  a  conceptual  design  of  the 
supply  chain  management  model  (SCMM)  that  will  serve  as  a  sparing  tool  to  bridge  the 
gap  that  currently  exists  in  the  support  of  modular  or  flexible  optimally-manned  ships. 
This  project  is  sponsored  by  Mr.  Robert  (Bob)  Howard  of  the  Naval  Surface  Warfare 
Center  (NSWC),  Port  Hueneme  Division  (PHD).  Mr.  Howard  is  the  Supportability 
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Manager  for  the  Land  Attack  Systems  Engineering  (SE)  and  Test  &  Evaluation  Division 
(E20).  This  capstone  project  report  summarizes  the  results  of  the  NFS  Cohort  311- 
123E’s  efforts  on  this  NSWC  PHD  sponsored  capstone  project.  It  also  outlines  the  SE 
process  used  and  documents  the  findings  in  each  phase  of  that  process. 

B.  PROJECT  BACKGROUND 

Mr.  Howard,  in  a  July  2013  meeting,  explained  that  the  U.S.  Navy  has  begun  to 
focus  acquisition  strategies  to  incorporate  more  modular  and  flexible  designs  for  surface 
ship  architecture  in  an  effort  to  improve  procurement  and  life  cycle  costs  and  to  support 
rapid  introduction  of  capability.  Modularity  in  this  emphasis  defines  an  approach  that 
subdivides  systems  into  smaller  parts  (modules)  that  can  be  independently  created  and 
then  used  in  different  systems  to  drive  multiple  functionalities  (Chief  Information 
Officer,  Department  of  Defense  2007).  Mr.  Howard  added  that  given  the  emphasis  on 
modularity,  the  Navy  is  also  placing  importance  on  personnel  requirements  that  are 
optimized  to  modular  or  flexible  constructs.  However,  Mr.  Howard  suggested,  as  the  U.S. 
Navy  drives  toward  more  modular  and  flexible  designs,  the  current  surface  Navy  supply 
chain  models  do  not  support  a  modular  architecture  nor  an  off  ship  maintenance  support 
structure  that  requires  multiple  logistics  and  repair  nodes  to  reflect  optimal  personnel 
requirements  or  supply  points  constrained  by  space  and  weight.  Examples  of  the  modular 
or  flexible  optimally-manned  ships  Mr.  Howard  referred  to  include  the  littoral  combat 
ship  (ECS)  and  DDG-1000.  DDG-1000  will  be  a  new  class  of  guided  missile  destroyers. 
It  was  developed  as  part  of  the  twenty-first  century  destroyer  program. 

In  an  interview  with  Mr.  Howard  and  the  team  on  August  23,  2013,  he  made  clear 
that  currently  ECS  personnel  originate  a  spares  list  but  not  from  a  model  or  quantitative 
analysis  because  the  current  RBS  model  does  not  support  this  maintenance  concept.  Mr. 
Howard  advised  that  the  Naval  Supply  Systems  Command  (NAVSUP)  also  affirms  that 
existing  models  or  algorithms  do  not  support  this  maintenance  concept;  they  are 
interested  in  efforts  to  solve  this  problem  because,  according  to  Mr.  Howard,  the  ECS 
program  office  needs  an  improved  means  to  maintain  ships  and  naval  readiness. 
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The  primary  objective  of  this  project  was  to  address  the  needs  of  the  stakeholders 
using  a  documented  systems  engineering  process  (SEP)  to  develop  a  supply  chain 
management  (SCM)  model  in  support  of  modular  or  flexible  optimally-manned  ships. 
During  the  stakeholder  analysis,  critical  assumptions  and  constraints  were  also  identified. 
According  to  an  article  posted  on  the  Loyola  University  Chicago  website: 

Each  assumption  is  an  ‘educated  guess,’  a  likely  condition,  circumstance 
or  event,  presumed  known  and  true  in  the  absence  of  absolute  certainty. 

Each  constraint  is  a  limiting  condition,  circumstance  or  event,  setting 
boundaries  for  the  project  process  and  expected  results.  Once  identified, 
these  assumptions  and  constraints  shape  a  project  in  specific,  but 
diverging  ways  -  assumptions  bring  possibilities,  and  constraints  bring 
limits.  (Loyola  University  Chicago  n.d.) 

Some  key  assumptions  used  in  this  analysis  were: 

•  Eunding  was  available  to  implement  this  SCMM. 

•  No  classified  information  was  transmitted  through  the  SCMM. 

•  The  model  can  be  used  by  any  modular  or  flexible  design  system. 
(Although  the  team’s  model  focused  on  ECS  as  a  proof  of  principle,  it  was 
assumed  that  the  model  can  be  used  by  any  modular  or  flexible  designed 
system.) 

In  addition  to  the  assumptions  listed  here,  the  team  assumed  certain  constraints. 
Team  RSRP’s  SCMM  was  constrained  by  the  requirement  to  be  interoperable  with  other 
software  systems  currently  used  by  the  stakeholders  and  hosting  platform  requirements. 

In  the  same  August  23,  2013,  discussion  with  Mr.  Howard,  he  continued  to 
explain  that  as  a  part  of  Department  of  Navy  (DoN)  acquisition  strategy,  acquisition 
personnel  are  looking  at  continuing  to  apply  a  modular  or  flexible  design  to  future  ships 
to  support  rapid  introduction  of  capability  in  support  of  multiple  missions.  As  part  of  this 
capability,  a  process  and  approach  for  optimizing  the  allocation  of  spares  at  the  war 
fighters’  level  and  at  multiple  maintenance  nodes  are  required.  The  current  manual 
process  comprises  a  team  of  logisticians  and  engineers  who  gather  recent  failure  data  and, 
along  with  the  subject  matter  experts’  knowledge  of  the  system,  use  this  information  to 
compile  a  spares  list  to  stock  parts  in  the  mission  module  container  that  will  be  employed 
onboard  ship.  The  process  used  to  calculate  spare  parts  to  support  the  ship,  maintenance. 
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and  warehouse  facilities  is  based  on  the  current  RBS  model,  which  has  proven  not  to 
meet  the  manning,  space,  and  weight  constraints  imposed  by  this  modular  or  flexible 
design. 

Mr.  Howard  continued  to  articulate  that  from  a  stakeholder  perspective,  this 
supply  chain  issue  is  a  very  real  problem.  As  he  explained,  even  after  many  meetings  and 
many  hours  spent  trying  to  resolve  the  issue  of  supply  chain  management  and  spares 
allocation,  there  are  still  ships  operating  with  a  list  of  spares  no  one  confirmed  is 
correct — (i.e.,  it  may  not  actually  match  up  with  the  spares  that  are  needed  based  on 
actual  or  quantitatively  derived  failures).  The  efforts  made  in  this  report  will  help  to 
rectify  this  problem,  and  it  is  hoped  that  these  efforts  will  contribute  significantly  to 
support  the  U.S.  Navy  fleet. 

C.  PROJECT  TEAM 

The  Systems  Engineering  Management  (SEM)  cohort  311-123E,  called  Team 
RSRP,  consisted  of  10  Naval  Postgraduate  School  (NPS)  students.  Eight  students  were 
from  NSWC  PHD  and  two  students  were  from  NSWC  Crane  Division  (CD).  In  order  to 
address  the  problem,  the  team  organized  and  completed  tasks  according  to  the  roles 
shown  in  Table  1. 


Role 

Team  Member 

Team  Eead 

Alain  DeEeon 

Scheduler 

Victoria  Woods  (lead),  Raymond  Chun 

Secretary 

Julie  Eigman  (lead).  Hang  Nguyen 

Modeler 

David  Eaulk  (lead),  Aaron  Oostdyk,  Alain 
DeEeon 

Editor 

Viviane  Bonagrazia-Healey  (lead),  Victoria 
Woods,  Julie  Eigman,  Brandon  Will,  Zachary 
Crane 

Sponsor  Eiaison 

Viviane  Bonagrazia-Healey 

Eibrarian 

Brandon  Will 

Eiterature  Reviewer 

Hang  Nguyen  (lead),  Victoria  Woods 

Table  1.  Team  Project  Roles  and  Personnel 
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The  Systems  Engineering  Management  Plan  (SEMP)  has  additional  details  on  the 
team  roles  and  responsibilities.  To  obtain  the  SEMP,  please  contact  Mr.  Raymond  Chun 
at  Raymond.Chun@navy.mil. 

D.  SYSTEMS  ENGINEERING  PROCESS 

To  develop  the  SCMM  system,  a  suitable  SEP  was  determined  for  the  project. 
There  are  various  lifecycle  development  models  that  have  been  created  and  applied  to 
system  development  projects.  These  models  are  used  throughout  government  and 
industry  and  are  based  on  one  of  three  influential  process  models:  the  waterfall  process 
model,  the  spiral  process  model,  and  the  “vee”  process  model. 

The  waterfall  process  model  is  a  sequential  design  process  in  which  progress  is 
seen  as  flowing  steadily  downwards,  like  a  waterfall,  ranging  from  a  series  of  five  to 
seven  steps  performed  sequentially  (Blanchard  and  Eabrycky  2011).  Introduced  by  Royce 
in  1970,  it  was  initially  used  for  software  development;  in  1981,  Boehm  expanded  the 
model  into  eight  steps  (Blanchard  and  Eabrycky  2011).  Each  step  is  completed  prior  to 
beginning  the  next  step;  the  phases  must  be  repeated  when  deficiencies  are  found 
(Blanchard  and  Eabrycky  2011).  The  main  drawback  of  the  waterfall  model  is  its  serial 
nature  as  this  requires  problems  to  be  fixed  before  proceeding  to  the  next  phase 
(Blanchard  and  Eabrycky  2011).  This  serial  nature,  thereby,  makes  it  difficult  to  tailor  to 
the  engineering  methodology  needed  to  support  this  project,  which  is  iterative  in  nature, 
meaning  that  as  the  team  progresses  through  the  various  phases  it  will  revisit  those  as 
more  information  becomes  available  and  changes  are  required. 

The  spiral  model  is  another  well-known  example  of  engineering  methodology 
used  for  software  development.  It  was  developed  by  Boehm  in  1986  using  Hall’s  work  in 
systems  engineering,  and  is  an  incremental  model  that  places  more  emphasis  on  risk 
analysis  (Blanchard  and  Eabrycky  2011).  The  project  repeatedly  passes  through  various 
phases  in  iterations  (spirals)  when  creating  a  prototype,  and  risk  within  the  prototype  is 
evaluated  prior  to  proceeding  to  the  next  phase  of  the  design  (Blanchard  and  Eabrycky 
2011).  The  spiral  model  is  a  variation  of  the  waterfall  model  (Blanchard  and  Eabrycky 
2011). 
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The  third  well-known  example  of  engineering  methodology  is  the  vee  process 
model  developed  in  1991  by  Forsberg  and  Mooz  (Blanchard  and  Fabrycky  2011).  It  also 
can  be  used  for  software  development  but  it  is  more  a  graphical  representation  of  a 
sequence  of  steps  in  developing  a  system  using  various  systems  engineering  phases 
(Blanchard  and  Fabrycky  2011).  On  the  left  side,  the  vee  model  identifies  the 
decomposition,  architecture,  and  detailed  design;  while  on  the  right,  the  component 
integration  and  system  validation  verifies  readiness  of  the  system  (Blanchard  and 
Fabrycky  2011).  This  model  is  simple  and  straightforward  with  analysis,  verification,  and 
testing  conducted  early  in  each  phase.  It  includes  a  top  down  and  bottom  up  approach  that 
allowed  for  process  tailoring. 

Based  on  the  three  different  SE  processes  researched,  the  waterfall  model,  the 
spiral  model,  and  the  vee  model,  team  RSRP  selected  the  vee  model.  The  other  two 
models  are  more  sequential,  and  were  not  a  good  fit  for  the  concept  of  the  capstone 
project.  The  vee  model  is  more  suitable  to  tailor  for  the  system  being  developed  and  the 
availability  of  the  team’s  personnel,  time,  and  expertise 

The  team  tailored  the  vee  model  to  reflect  the  unique  needs  of  the  SCMM  system 
development  accounting  for  the  project  schedule,  organizational  structure,  and  the  type  of 
system  being  developed.  The  vee  model  and  the  team’s  tailored  SE  vee  model  are  shown 
in  Eigure  1 .  The  tailored  SE  vee  model  started  with  defining  customer  wants  on  the  upper 
left  and  ended  with  validation  on  the  upper  right.  The  left  side  had  the  decomposition  and 
definition  activities,  including  identification  of  the  system  requirement,  system 
architecture,  conceptual  design  and  modeling  and  simulation.  The  system  integration  and 
test  activities  flow  upward  to  the  right  as  different  levels  of  the  design  were  verified  and 
validated:  this  included  component  verification,  system  analysis  and  system  validation. 
At  each  level  of  verification,  the  original  requirement  was  compared  to  ensure  the  design 
met  the  specification.  A  concurrent  approach  was  used  to  ensure  the  design  was 
supportable,  functionally  capable,  and  maintainable.  This  resulted  in  the  design  of  the 
product  meeting  the  customers’  needs  as  the  team  progressed  through  the  various  phases 
of  the  Systems  Engineering  Process  (SEP).  The  review,  evaluation,  and  feedback  process 
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were  continuous  throughout  system  design  and  development.  (Forsberg  and  Mooz  1991). 
The  end  result  of  this  SEP  should  be  a  conceptual  design  of  the  SCMM  system  to  support 
modular  and  flexible  design  ships. 


The  SE  "Vee"  Process 


1.  Needs  Analysis 

The  first  phase  of  the  tailored  SEP  was  to  understand  the  stakeholders’  needs, 
wants,  and  desires.  Stakeholder  and  need  analyses  were  conducted  to  further  develop  the 
initial  problem  statement  and  to  refine  the  primitive  need  statement  into  an  effective  need 
statement.  The  problem  statement  and  effective  need  statement  were  accepted  by  the 
sponsor.  Following  these  steps,  a  functional  analysis  was  conducted  to  determine  what 
the  SCMM  system  must  do.  A  functional  flow  block  diagram  (FEED)  was  created  in 
CORE.  Blanchard  and  Fabrycky  state  that  functional  flow  block  diagrams  (FEBDs)  are 
used  “...to  describe  the  system  and  its  elements  in  functional  terms”  (2011,  699).  FEBDs 
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reflect  “...operational  and  support  activities... and  they  are  structured  in  a  manner  that 
illustrates  the  hierarchical  aspects  of  the  system”  (Blanchard  and  Fabrycky  2011,  699).  It 
was  very  important  to  identify  and  organize  the  functions  and  sub-functions  in  a 
meaningful  way  allowing  for  generation  (or  analysis)  of  alternatives  during  the 
conceptual  design  phase  (Chapman,  Bahill  and  Wymore  1992).  It  also  helped  to  ensure 
that,  during  the  team’s  SEP  conceptual  design  phase,  the  design  alternatives  would  meet 
the  needs  of  the  stakeholders  (Chapman,  Bahill  and  Wymore  1992). 

2.  System  Requirements 

Once  the  problem  and  effective  need  statements  were  defined,  agreed  upon  by  the 
sponsor,  and  understood  by  the  stakeholders,  a  system  requirements  analysis  was 
conducted  based  on  the  Buede  method  for  requirements  analysis.  Input-output  analysis 
was  conducted  to  scope  and  bound  the  problem.  An  input,  control  /  constraint,  output, 
and  mechanism  (ICOM)  diagram  and  Context  diagram  were  developed  as  a  result  of 
these  analyses.  Functional  and  non-functional  requirements  were  identified  from  the 
system  requirements  development  based  on  the  previously  conducted  functional  analysis 
of  the  system.  The  system’s  requirements  were  captured  in  Vitech’s  CORE,  a  systems 
engineering  and  project  management  toolset  that  was  used  to  trace  the  system 
requirements  to  stakeholder  needs,  document  system  functionality,  and  document  the 
system  architecture.  This  phase  was  needed  to  complete  the  design  to  sufficient  detail  for 
a  specification  to  be  delivered  to  the  design  teams  responsible  for  the  configuration  items 
of  the  system.  The  team  was  unable  to  develop  the  design  to  the  level  of  detail  required 
for  configuration  items  to  be  identified,  but  did  provide  a  set  of  requirements  that  could 
be  further  decomposed  to  reach  this  level  of  specification. 

3.  System  Architecture 

The  system  architecture  (SA)  phase  captured  the  logical  sequencing  and 
interaction  of  system  functions  or  logical  elements.  The  system  architecture  was 
documented  using  CORE,  which  also  provided  a  model  based  systems  engineering 
(MBSE)  capability.  The  team  utilized  the  Department  of  Defense  Architecture 
Framework  v2.02  (DODAF)  to  define  the  different  architecture  views  of  the  system 
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design.  This  framework  outlines  a  common  approach  for  DOD  architecture  description, 
development,  presentation,  and  integration  (Vickers  and  Charles-Vickers  2006).  Three 
architectural  views,  capability  view  (CV),  operational  views  (OVs),  and  system  views 
(SVs),  were  created  to  show  the  relationship  of  inputs  and  outputs  and  constraints  and 
mechanisms  of  the  system  design.  The  output  of  this  phase  was  a  high  level  system 
design  and  a  developing  architecture  that  met  the  needs  of  the  stakeholders. 

4.  Conceptual  Design 

The  purpose  of  this  phase  was  to  initially  identify  a  system  design  that  met  the 
functional  and  performance  requirements  of  the  SCMM  system.  The  conceptual  design 
was  accomplished  in  conjunction  with  the  system  analysis  phase  by  conducting  an 
analysis  of  alternatives  (AoA).  The  team  used  this  phase  to  narrow  down  the  best 
alternative  to  meet  the  needs  of  the  stakeholders/sponsor. 

5.  Modeling  and  Simulation 

During  this  phase,  the  conceptual  design  of  the  SCMM  system  was  modeled  using 
various  methods,  including  simulation,  to  determine  expected  system  performance  or 
behavior.  The  modeling  and  simulation  (M&S)  output  provided  insights  about  the  design 
solutions,  empirical  data  on  performance,  effectiveness,  and  processes. 

6.  System  Integration  and  Test 

In  this  phase,  system  elements  are  assembled,  integrated,  and  tested  to  evaluate 
the  system  design.  The  system  integration  and  testing  verifies  performance  characteristics 
and  identifies  design  issues  to  stakeholders.  Trade-off  studies,  including  readiness  and 
maturity  of  the  system  design,  should  be  conducted.  Due  to  this  capstone  project’s 
schedule  constraint,  system  integration  and  test  included  system  verification,  system 
analysis,  and  system  validation  of  the  SCMM  system  simulation  that  was  created  in  the 
M&S  phase.  This  phase  was  accomplished  concurrently  with  the  M&S  phase  to  ensure 
the  simulated  system’s  effectiveness  and  suitability. 
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7.  Component  Verification 

Component  verification  of  all  levels  of  the  architecture  is  conducted  through  an 
effective  combination  of  analysis,  inspection,  demonstration,  and  testing.  This  gauges  the 
maturity  of  each  component  (i.e.,  software  [SAV]  and  supportability)  prior  to  integrating 
the  overall  system  design  solution.  The  team  did  not  perform  this  phase  of  the  SEP  due  to 
the  immaturity  of  the  system  design. 

8.  System  Analysis 

During  the  system  analysis  phase  design  alternatives  were  evaluated  by 
conducting  an  AoA  to  identify  potential  solutions  that  could  satisfy  the  requirements  and 
support  a  decision  based  on  the  most  effective  solution.  Blanchard  and  Fabrycky  state 
that  an  AoA  “...  facilitates  determination  by  the  customer  of  the  best  design  alternative 
based  on  the  results  of  modeling  and  analysis...”  (2011,  169).  The  AoA  was  conducted 
using  value  modeling,  based  on  a  weighted  chart,  and  with  a  numerical  evaluation  matrix 
to  determine  the  model  that  best  satisfied  the  stakeholders’  requirements  (Buede  2000). 

Cost  analysis  was  conducted  during  this  phase  to  evaluate  the  different 
alternatives.  The  constructive  systems  engineering  cost  model  (COSYSMO)  was  used  to 
evaluate  the  different  alternatives  that  resulted  from  the  AoA  conducted  during  the 
conceptual  design  phase.  Use  of  COSYSMO  allowed  the  team  to  help  assess  the  cost  and 
schedule  implications  of  systems  engineering  decisions. 

Risk  analysis  was  conducted  throughout  the  SEP  focusing  on  the  SCMM  system 
and  capstone  project  risks.  This  analysis  resulted  in  the  development  of  the  Risk 
Management  Plan  addressing  the  programmatic  and  technical  risks  of  the  project  and 
system. 

The  output  of  this  phase  was  the  identification  of  a  system  alternative  suitable  for 
adaptation  to  support  the  stakeholders’  needs  and  requirements.  The  risk  analysis  resulted 
in  the  development  of  the  Risk  Management  Plan  addressing  the  programmatic  and 
technical  risks  of  the  project  and  system. 
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9.  System  Validation 

System  validation  ensures  that  the  as-designed  system  meets  the  system 
requirements  in  conformance  with  the  stakeholders’  needs  (Blanchard  and  Fabrycky 
2011).  This  process  also  demonstrates  that  the  designed  system  achieves  its  intended  use 
in  the  intended  operational  environment  (Blanchard  and  Fabrycky  2011).  Although  this 
phase  was  not  performed  in  its  entirety  due  to  the  immaturity  of  the  system  design,  it  is 
recommended  that  system  validation  continue  throughout  the  design  of  the  SCMM 
system  by  performing  progressive  and  iterative  integrated  system  testing  to  validate  the 
maturity  of  the  system  and  assess  overall  system  readiness.  Recommendations  on  how  to 
conduct  the  validation  can  be  found  in  the  System  Integration  and  Test  chapter. 

10.  SE  Process  Status 

The  SEP  in  its  entirety  was  not  completed  due  to  the  time  constraints  of  the 
capstone  project’s  timeframe.  Figure  2  provides  a  reference  point  for  each  of  the  phases 
and  their  completion.  The  needs  analysis  phase  is  complete,  signaled  by  a  star;  the  system 
requirements,  system  architecture,  conceptual  design,  modeling  and  simulation,  system 
integration  and  test,  system  analysis,  and  system  validation  phases  require  additional  time 
and  development  to  complete  the  SCMM  system,  signaled  by  a  check.  The  component 
verification  phase  could  not  be  accomplished,  signaled  by  an  “x.” 
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Figure  2. 


Systems  Engineering  Process  Status  (after  Forsberg  and  Mooz  1991) 


E.  SYSTEM  LIFECYCLE 

In  order  to  develop  the  SCMM  system,  it  was  important  to  consider  the  system 
lifecycle,  and  break  down  the  product  life  cycle  into  two  phases:  the  acquisition  phase 
and  the  utilization  phase  (Blanchard  and  Fabrycky  2011).  The  acquisition  phase  begins 
with  the  need  and  conceptual  /  preliminary  design  stage,  followed  by  the  detailed  design 
and  development  and  production  stages.  The  utilization  phase  includes  the  operations  and 
support  stage  of  the  system  and  the  disposal  stage.  These  phases  and  stages  are  illustrated 
in  Figure  3.  The  work  for  this  capstone  project  was  conducted  under  the  acquisition 
phase,  in  particular,  the  need  and  conceptual  /  preliminary  design  stage. 
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ACOl'ISITION  PHASE 


UTILIZATION  PHASE 


Figure  3.  Life  Cycles  of  the  System  (from  Blanchard  and  Fabrycky  2011,  30) 


According  to  Blanchard  and  Fabrycky: 

Life-cycle  guided  design  is  simultaneously  responsive  to  customer  needs  (i.e.,  to 
requirements  expressed  in  functional  terms)  and  to  life-cycle  outcomes.  Design 
should  not  only  transform  a  need  into  a  system  configuration  but  should  also 
ensure  the  design’s  compatibility  with  related  physical  and  functional 
requirements,  Further,  it  should  consider  operational  outcomes  expressed  as 
producibility,  reliability,  maintainability,  usability,  supportability,  serviceability, 
disposability,  sustainability,  and  others,  in  addition  to  performance,  effectiveness, 
and  affordability.  (Blanchard  and  Fabrycky  2011,  30-31) 

Correspondingly,  and  in  line  with  the  team’s  modified  vee  systems  engineering 
process.  Table  2  depicts  the  technical  activities  that  were  conducted  during  the 
acquisition  phase,  in  particular  the  conceptual  /  preliminary  design  stage,  and  how  each 
of  those  corresponds  to  the  team’s  modified  vee  SEP,  using  as  a  guide  the  information 
found  in  Systems  Engineering  and  Analysis  (Blanchard  and  Fabrycky  201 1,  32  and  34). 
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Acquisition  Phase 

Technical  Activities 

Vee  SEP  Phase 

Conceptual  Design 

Problem  Definition, 

Need  Identification, 
Stakeholder  Analysis, 
Eunctional  Definition 
of  System;  Eunctional 
Analysis 

Needs  Analysis 

Conceptual  Design 

Requirements  Analysis; 
Operational 
Requirements, 
Performance  Measures 

System  Requirements 

Preliminary  Design 

Requirements 

Allocation 

System  Requirements 

Conceptual  Design 

Capability  and 
Operational  Views 

System  Architecture 

Preliminary  Design 

System  Views 

System  Architecture 

Conceptual  Design 

Evaluation  of 
Technology 

Conceptual 

Design/System 

Analysis 

Preliminary  Design 

Trade-off  Studies, 
Analysis  of 

Alternatives,  Synthesis 

Conceptual 

Design/System 

Analysis 

Preliminary  Design 

Evaluation  of  Design, 
Evaluation  of  Design 
Alternatives 

Modeling  and 
Simulation/Integration 
and  Test/System 
Validation 

Table  2.  Acquisition  Phase  Technical  Activities  and  the  Vee  SEP 


The  system  integration  and  test  phase  and  the  system  validation  phase  were 
performed  to  some  extent  but  not  in  their  entirety  due  to  the  immaturity  of  the  system 
design.  The  component  verification  phase  was  not  performed  for  the  same  reason.  System 
analysis  for  risk  was  performed  throughout  the  project  and  design/development  of  the 
SCMM  system. 

F.  TECHNICAL  TOOLS 

Tools  for  this  project  included  the  Microsoft  Office  suite,  Vitech’s  CORE, 

Imaginethat  Inc.’s.  ExtendSIM,  and  Ricardo  Valerdi’s  COSYSMO,  as  applicable.  CORE 

is  a  robust  systems  engineering  and  project  management  tool  that  allows  the  user  to 

quickly  house  and  document  important  data  pertinent  to  systems  engineering  problems. 
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ExtendSIM  is  a  simulation  program  for  modeling  discrete  and  continuous  events. 
COSYSMO,  the  constructive  systems  engineering  cost  model,  estimates  the  person- 
months  required  to  staff  hardware  and  software  projects.  The  NFS  Sakai  site  and  the 
services  it  provided  were  used  as  the  primary  collaboration  environment  for  the  team 
members.  These  tools  were  provided  for  use  by  the  Naval  Postgraduate  School  during  the 
course  of  the  Systems  Engineering  Management  program. 

G.  SUMMARY 

The  Navy’s  supply  chain  is  an  extensive  and  integral  component  for  sustainment 
operations  ensuring  ship  mission  readiness.  A  new  approach  to  allocating  repair  parts  in 
support  of  readiness  must  be  developed  and  implemented  to  optimally  sustain  emerging 
ship  classes  that  utilize  modular  or  flexible  design  equipment  for  increased  mission 
capabilities.  Project  team  RSRP  began  the  research  and  development  of  closing  this 
capability  gap  in  the  Navy’s  supply  chain  management  by  applying  system  engineering 
techniques  to  create  the  foundation  for  the  supply  chain  management  model  (SCMM) 
system  that  considers  ship  constraints  for  weight,  space,  and  available  manpower  to 
provide  the  user  with  identified  repair  parts  and  allocation. 

Team  RSRP’s  methodology  began  with  identifying  team  member  roles  and 
responsibilities  to  ensure  efficient  project  development  coverage.  After  a  team  structure 
was  established,  the  team  tailored  the  vee  SEP  to  reflect  the  unique  needs  of  the  SCMM 
system  development.  This  tailored  vee  included  the  following  main  developmental 
process  phases:  needs  analysis,  system  requirements,  system  architecture,  conceptual 
design,  modeling  and  simulation,  system  integration  and  test,  component  verification, 
system  analysis,  and  system  validation.  The  system  lifecycle  was  considered  during 
project  development.  While  the  majority  of  the  work  completed  during  this  capstone  was 
conducted  under  the  acquisition  phase,  system  characteristics  of  the  utilization  phase 
were  considered  during  development  to  help  transition  to  future  system  fielding  and  use. 
The  technical  tools  utilized  were  made  available  by  the  Naval  Postgraduate  Systems 
Engineering  Management  program  and  were  implemented  during  the  research, 
architecting,  design,  and  modeling  and  simulation  phases  of  the  project. 
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The  team  worked  in  conjunction  with  the  project  sponsor,  Mr.  Howard,  NSWC 
PHD,  to  identify  and  understand  the  problem,  gaps,  and  requirements  necessary  for 
system  development.  Chapters  within  this  report  will  show  how  the  system  development 
evolved  from  an  identified  need  to  conceptual  design  of  the  SCMM  system,  following  the 
vee  SEP,  to  sustain  the  emerging  flexible  and  modular  ships  of  the  U.S.  Navy. 
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II.  NEEDS  ANALYSIS 


The  objective  of  the  needs  analysis  phase  was  to  understand  the  stakeholders’ 
needs,  wants,  and  desires  and  to  further  develop  the  initial  problem  statement  and  refine 
the  primitive  need  statement  into  an  effective  need  statement.  A  literature  review  was 
conducted  to  examine  the  material  related  to  SCM  for  modular  ships,  and  to  discover  the 
challenges  associated  with  it.  The  problem  statement  was  finalized,  and  the  gap  (the 
difference  between  the  current  state  of  the  system  and  how  the  stakeholder  needs  the 
system  to  perform  and  operate)  was  identified.  A  stakeholder  analysis  was  conducted  to 
determine  their  needs  and  develop  the  effective  need  statement.  A  functional  analysis  was 
then  performed  to  identify  the  critical  functions  of  the  system  by  developing  use  case 
scenarios. 

A.  PROBLEM  DEFINITION 

The  purpose  of  the  problem  definition  was  to  develop  a  final  problem  statement 
approved  by  the  sponsor.  This  required  analysis  and  communication  with  the  sponsor  that 
resulted  in  the  final  project  scope  and  an  understanding  of  the  system  boundaries.  Mr. 
Howard’s  statement  in  the  July  23,  2013,  meeting  with  the  team  provided  the  original 
problem  definition:  Current  surface  Navy  supply  chain  models  do  not  support  a  modular 
architecture  and  an  off  ship  maintenance  support  structure  requiring  multiple  logistics 
and  repair  nodes  to  reflect  optimal  manning  or  constrained  physical  and  weight 
constrained  supply  points. 

I.  Research  Questions 

Based  on  the  problem  statement,  the  team  used  the  following  questions  to  guide 
the  literature  review  and  research: 

•  What  are  modular  or  flexible  ship  designs? 

•  What  is  meant  by  “optimal  manning”? 

•  What  are  other  organizations  using  for  SCM  models  in  support  of  modular 
or  flexible  design? 
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•  How  do  shipboard  space  and  weight  constraints  affect  modular  or  flexible 
designed  ship? 

•  What  metrics  can  be  used  to  assess  sparing  model  performance? 

•  Why  does  the  gap  (problem)  exist?  What  sources  help  to  explain  the  gap? 

•  What  metrics  can  be  used  to  assess  sparing  model  performance? 

2.  Literature  Review 

Using  the  research  questions,  the  team  searched  available  literature  including 
scholarly  articles,  journals,  and  reports  to  examine  the  material  related  to  SCM  for 
modular  ships  and  to  discover  the  challenges  associated  with  it.  In  the  review  of  the 
literature,  the  team  found  information  that  included  examples  of  SCM  in  the  DOD: 
information  about  warehouse  management  processes;  examples  of  time-based 
distribution  of  parts  and  supplies;  examples  of  different  inventory  management  methods; 
and  sea-frame  constraints  of  the  U.S.  Navy’s  modular  ship  class  LCS.  The  capstone  team 
used  the  research  questions  to  focus  the  research  on  areas  related  to  modular  or  flexible 
ship  design  characteristics,  logistics  support  requirements,  supply  chain  management 
methods,  and  modeling  methods.  Systems  engineering  processes  were  also  investigated 
to  determine  a  methodology  suitable  for  project  use. 

A  portion  of  literature  review  focused  on  the  Navy’s  LCS  use  of  emerging 
technology  associated  with  robotic  packages  (unmanned  air,  surface,  and  underwater 
vehicles)  and  modular  weapons  and  sensors  (Sayen  2012).  The  modular  systems  utilizes 
different  payload  packages  (modules),  which  are  each  designed  to  fit  a  common 
cargo/weapons  bay  or  slot  and  focus  the  ship  on  a  specific  mission:  LCS  mission  modules 
include  packages  for  mine  warfare  (MIW),  anti-submarine  warfare  (ASW),  anti-air 
warfare  (AAW),  and  anti-surface  warfare  (ASUW)  (Sayen  2012).  When  a  ship’s  mission 
changes,  it  can  quickly  exchange  its  current  module  for  one  that  reinforces  the  alternate 
mission;  a  quick  exchange  of  modules  is  an  attempt  to  obtain  the  benefits  of  both  single 
and  multi-mission  platforms  (Sayen  2012).  SCM  plays  a  critical  role  in  achieving  the  end 
goal  of  supporting  modular  or  flexible  design  ships.  Military  supply  chain  management  is 
the  discipline  that  integrates  acquisition,  supply,  maintenance,  and  transportation 
functions  with  the  physical,  financial,  information,  and  communications  networks  in  a 
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results-oriented  approach  to  satisfy  joint  force  materiel  requirements  (Joint  Chiefs  of 
Staff  2013).  SCM  works  to  develop,  design,  and  deliver  optimal  material  support  while 
maximizing  resources  to  provide  the  right  parts  at  the  right  time  to  better  allow  for  the 
sustainment  of  weapon  systems  throughout  their  life  cycle  (Joint  Chiefs  of  Staff  2013). 

LCS  operates  with  a  minimal  but  cross-trained  ship  force  (Defense  Industry  Daily 
2014).  A  cross-trained  crew  is  one  that  can  operate  multiple  systems  on  the  same  ship. 
On  other  ship  classes  these  systems  are  normally  operated  by  a  system  specific  trained 
operator.  For  example,  a  sailor  is  specifically  trained  to  become  a  subject  matter  expert 
(SME)  and  operate  the  Rolling  Airframe  Missile  system.  A  different  sailor’s  specialty 
might  be  the  57mm  gun.  These  two  sailors  typically  do  not  have  training  on  how  to 
operate  each  other’s  equipment.  According  to  the  Defense  Industry  Daily  website,  the 
LCS  class  ships  are  “...intended  to  operate  with  a  core  crew  of  40  sailors,  plus  a  mission 
module  detachment  of  15  crew  and  an  aviation  detachment  of  25  crew”  (Defense 
Industry  Daily  2014).  Mission  types  include  mine  warfare  (MIW),  24  crew  planned;  anti¬ 
submarine  warfare  (ASW),  16  crew  planned;  and  anti-surface  warfare  (ASUW),  24  crew 
planned  (Defense  Industry  Daily  2014).  Each  ship  has  a  pair  of  40-person  crews  (Blue 
and  Gold),  which  will  shift  to  three  crews  over  time  that  can  deploy  in  four-month 
rotations.  (Defense  Industry  Daily  2014)  The  website,  on  its  webpage  “LCS:  The  USA’s 
Littoral  Combat  Ships,”  states  that  “There  are  concerns  that  this  is  a  design  weakness, 
leaving  the  LCS  crew  at  the  edge  of  its  capabilities  to  just  run  the  ship,  with  insufficient 
on-board  maintenance  capabilities”  (Defense  Industry  Daily  2014).  The  team  concluded 
that  due  to  the  personnel  constraint  on  the  LCS  ship  class  described  on  the  “LCS:  The 
USA’S  Littoral  Combat  Ships”  webpage,  the  ships  will  rely  heavily  on  SCM  for  distance 
support  processes  and  applications  to  fully  enable  the  operational-manning  of  these 
optimally  crewed  ships.  The  preventative,  predictive,  condition-based,  and  corrective 
maintenance  and  logistics  functions  for  spare  parts  and  repairs  will  be  partially  or 
completely  absorbed  by  shore-based  infrastructure  due  to  the  reduced  shipboard 
personnel. 

In  a  2013  article  on  the  America’s  Navy  website.  Sky  M.  Laron,  Yokosuka 
Director  of  Corporate  Communications  at  NAVSUP’s  Elect  Logistics  Center  (LLC), 
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quoted  Commander  Mark  Sheffield,  NAVSUP  FLC  Yokosuka  Operations  Director,  who 
stated:  “[Logistics  Support  Teams]  conducted  a  continual  planning  analysis  to  ascertain 
both  the  known  and  unknown  of  the  very  specific  support  requirements  that  are  needed 
by  the  Navy’s  newest  minimally  manned  platform”  (Laron  2013).  Laron,  in  the  same 
2013  article,  also  quoted  Commander  Jerry  King,  NAVSUP  FLC  Yokosuka,  Site 
Singapore  Director,  who  stated:  “Fast,  efficient  and  comprehensive  support  in  logistics 
and  contracting  continues  to  be  challenging  but  very  successful.  By  ensuring  our  shore 
infrastructure  is  resourced  properly  we  will  maintain  long  term  success  of  multiple  LCS 
platforms  abroad”  (Laron  2013).  Laron  credits  flexibility  as  a  key  factor  in  successfully 
meeting  LCS’s  requirements  portside  (Laron  2013).  These  statements  further  justify  the 
need  for  an  effective  SCM  model  to  support  modular  or  flexible  design  ships. 

For  the  Army,  the  supply  concepts  have  to  be  integral  to  the  modern  battlefield. 
The  Army  must  optimal  logistical  support  to  maximize  its  combat  power  in  order  to 
provide  timely,  efficient,  and  effective  logistical  support  to  operational  units.  The  Army 
supply  chain  management  process  provides  items  necessary  to  equip,  maintain,  and 
operate  a  military  command.  If  there  is  a  supply  shortage  such  as  ammunition,  fuel,  or 
repair  parts  during  the  missions,  it  can  cause  units  in  the  missions  to  reach  their 
terminating  point  before  they  accomplish  the  operation.  (Department  of  the  Army 
Headquarters  2000)  These  same  concepts  are  analogous  to  the  needs  of  the  Navy,  as  well, 
in  terms  of  supply  concepts.  Army  logistics  needs  to  demonstrate  five  essential 
characteristics:  initiative,  agility,  depth,  versatility,  and  synchronization  for  successful 
support  operations.  (Department  of  the  Army  Headquarters  2000,  1-1)  These  five 
characteristics  are  defined  in  Table  3  and  the  supply  applicability  is  detailed  therein. 
These  characteristics  are  also  applicable  to  Navy  logistics  for  successful  support  of 
operations. 
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TENET 

DEEINITION 

SUPPEY  APPEICABIEITY 

INITIATIVE 

Setting  or  changing  the 
terms  of  battle  by  action. 

Thinking  ahead  and  anticipating 
future  requirements  while 

planning  supply  needs  beyond 
the  current  operation. 

AGIEITY 

The  ability  of  friendly 
forces  to  act  faster  than  the 
enemy. 

Physical  agility  depends  upon 
the  right  quantity  of  supplies, 
both  enough  but  not  too  much. 
Mental  agility  can  be  affected  by 
low  morale  or  poor  health, 
which  can  be  caused  by  the 
wrong  amount  of  supplies,  for 
example;  food,  water,  clothing. 

DEPTH 

The  extension  of  operations 
in  space,  time,  and 
resources. 

Proper  use  of  supplies  plays  a 
critical  role  in  achieving  and 
maintaining  momentum  in  the 
attack  and  elasticity  in  the 
defense. 

VERSATIEITY 

The  ability  to  tailor  forces 
and  move  rapidly  and 
efficiently  from  one  mission 
to  another. 

The  successfulness  of  moving 
from  one  mission  to  another  will 
not  be  efficient  if  the  supplies 
are  not  in  the  right  place  at  the 
right  time. 

SYNCHRONIZATION 

The  arrangement  of 

battlefield  activities  to 
produce  maximum 
combat  power  at  the 
decisive  point. 

If  supply  support,  especially 
ammunition  and  fuel,  is  not 
correctly  synchronized,  units 
will  fail  to  achieve  maximum 
combat  power  at  critical 
moments. 

Table  3.  Tenets  of  Army  Operations  (from  Department  of  the  Army  Headquarters 

2000,  1-2) 


Team  RSRP  identified  metrics  from  the  Defense  Acquisition  University  (DAU) 
that  could  be  used  to  assess  the  performance  of  the  SCMM.  Common  supply  support 
metrics  include: 

•  Customer  Wait  Time:  The  time  (days  or  hours)  a  system  is  inoperable  due 
to  delays  in  maintenance  caused  directly  by  delays  in  obtaining  parts. 

•  Stock  Availability:  The  percentage  of  requisitions  that  are  filled 
immediately  from  stock  on  hand. 

•  Backorder  Rate:  The  ratio  of  “Out  of  Stock  Material”  to  “Total  Demand” 
for  a  given  weapon  system. 
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•  Order/Ship  Time:  The  elapsed  time  between  the  initiation  of  a  stock 
replenishment  action  by  a  specific  activity  and  the  receipt  of  material  by 
that  activity.  (Defense  Acquisition  University  2012,  17) 

In  the  article  titled  “The  Wrong  Ship  at  the  Wrong  Time,”  Commander  Patch, 

U.S.  Navy  (retired)  stated  that  the  basic  problem  of  the  LCS  is  that  from  inception  the 

Navy  inadequately  attempts  to  design,  build,  deploy,  and  sustain  a  fragile  size  warship  to 

do  too  many  things  (Patch  2011).  Commander  Patch  also  identified  that  staging  of  the 

modules  and  personnel  requires  a  forward  sea-base  or  shore  facilities  which  results  in  a 

heavy  logistics  footprint  (Patch  2011).  In  addition.  Commander  Patch  discussed  the 

impact  of  weight,  and  that  the  excessive  high-end  requirements  increasing  hull  machinery 

and  combat  system  weight  negatively  affect  the  ship’s  stability  (Patch  2011).  Plus,  the 

insufficient  passageway  and  support  requirements  for  aircraft,  unmanned  vehicles,  and 

module  detachments  have  exceeded  ship  capacity  (Patch  2011).  A  Government 

Accountability  Office  (GAO)  report.  Defense  Acquisitions:  Navy ’s  Ability  to  Overcome 

Challenges  Facing  the  Littoral  Combat  Ship  Will  Determine  Eventual  Capabilities ,  stated 

that  the  Navy  is  at  risk  of  “investing  in  a  fleet  of  ships  that  does  not  deliver  its  promised 

capability”  (Government  Accountability  Office  2010,  24). 

In  order  to  address  the  sponsor’s  concern  about  the  current  Navy  SCM  process  the 
next  step  was  to  define  the  current  Navy  SCM  process.  Following  is  the  result  of  research 
conducted  into  the  current  Navy  supply  chain  management  process. 

According  to  the  Assistant  Secretary  of  Defense: 

RBS  is  the  practice  of  using  advanced  analytics  to  set  spares  levels  and 
locations  to  maximize  system  readiness.  RBS  has  been  part  of  Department 
practice  since  the  1960s,  when  it  was  used  to  optimize  aircraft  availability, 
and  is  incorporated  into  DOD  Supply  Chain  Materiel  Management 
Regulation,  (DOD  4140. 1-R)  as  the  preferred  method  for  calculating 
inventory  levels.  The  Services  and  the  Defense  Logistics  Agency  (DLA) 
have  agreed  to  work  together  to  implement  Commercial-Off-The-Shelf 
(COTS)  based  RBS  models.  (Assistant  Secretary  of  Defense,  Logistics 
and  Materiel  Readiness  2012) 

RBS  is  a  requirements  determination  process  that  computes  the  levels  of 
secondary  item  spares  needed  to  support  a  weapon  system  readiness  goal  at  the  lowest 

possible  cost.  RBS  algorithms  determine,  for  each  inventory  location  (supply  and 
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maintenance),  the  lowest  cost  spares  mix  that  will  provide  the  required  operational 
readiness  level  for  a  weapon  system.  Figure  4  depicts  the  current  readiness  based  spares 
functional  scope,  obtained  from  the  RBS  Working  Group  presentation  located  on  the 
“Supply  Chain  Integration”  webpage. 
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Figure  4. 


Current  Readiness  Based  Spares  Functional  Scope  (from  RBS  Working 

Group  2005) 


The  DOD  Supply  Chain  Materiel  Management  Regulation,  DOD  4140.1 -R, 
mandates  that  RBS  models  be  used  whenever  possible  to  assess  inventory  investment 
required  for  fielding  new  programs  (i.e.,  weapon  systems  or  subsystems)  and  to  set 
sparing  levels  for  secondary  items  that  have  support  goals  related  to  weapon  system 
readiness  (DOD  Supply  Chain  Materiel  Management  Regulation,  DOD  4140. 1-R  2003). 
In  addition  to  these  primary  objectives,  RBS  analytical  capabilities  are  used  to  negotiate 
performance-based  supplier  agreements;  assess  the  effect  of  reliability,  maintainability, 
and  supportability  improvements  on  weapon  system  readiness;  budgets;  and  conduct 
what-if  exercises  related  to  deployments  (Assistant  Secretary  of  Defense,  Logistics  and 
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Materiel  Readiness  2012).  The  military  uses  RBS  models  in  various  levels  of  detail  and 
complexity.  See  Figure  5,  Multi-Indenture,  Multi-Echelon  (MIME)  RBS,  for  a  graphical 
representation  of  an  example  model,  obtained  from  the  “Supply  Chain  Integration” 
webpage.  Several  excellent  examples  of  legacy  software  tools  were  developed  internally 
by  the  Services  and  are  now  used  to  support  high  levels  of  system  readiness  (Assistant 
Secretary  of  Defense,  Logistics  and  Materiel  Readiness  2012). 
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Readiness-Based  Sparing  determines  the  inventory 
requirements  for  achievement  of  readiness  goals 


-  What  to  stock:  parts,  components,  sub-systems  {miJti-itxlenture) 

-  Where  to  stock:  at  strategic  distribution  points  (SDPs),  forward  distribution  points 

(FDPs),  and/or  at  squadron-level  or  operational  distribution  points,  {multi-echelon) 

-  Together  make  up  two-dimensional  Multi-indenture,  Multi-echelon  (MIME)  RBS 


Multi-indenture;  RBS  assesses 
trade-offs  within  various  parts, 
components,  and  sub-systems 
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Multi-echelon:  RBS  assessestrade- 
offs  of  stocking  levels  for  individual 
and/or  multiple  distribution  points 


Figure  5.  Multi-Indenture,  Multi-Echelon  RBS  (from  Assistant  Secretary  of 
Defense,  Logistics  and  Materiel  Readiness  2012) 


Having  no  weapon  systems  of  its  own,  DLA  does  not  tie  its  inventory  levels 
directly  to  a  weapon  system  readiness  target — the  traditional  definition  of  RBS;  however, 
DLA  does  take  advantage  of  the  mathematical  approach  inherent  in  RBS  models  to 
determine  more  efficient  and  effective  inventory  levels  in  a  multiple-echelon 
environment  (Department  of  Defense  2008).  In  this  context,  DLA  must  compute 
requirements  to  meet  a  different  goal,  such  as  customer  wait  time  (Department  of 
Defense  2008). 
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The  Assistant  Secretary  of  Defense  states  that  “Individualized  RBS  solutions 
address  the  service-unique  missions,  forces,  maintenance  philosophies,  weapon  systems 
requirements,  and  ERP  systems  environment,  as  indicated  on  the  Readiness  Based 
Sparing  Overview  presentation  located  on  the  “Supply  Chain  Integration”  webpage 
(Assistant  Secretary  of  Defense,  Logistics  and  Materiel  Readiness  2008,  3).”  The 
Assistant  Secretary  of  Defense  also  stated  that  a 

...RBS  Working  Group  was  established  by  the  Supply  Chain  Capabilities 
Group  to  share  knowledge  and  research  about  RBS;  share  progress  and 
lessons  learned  from  RBS  efforts’  to  define  interoperability;  and  to 
implement  a  DOD-wide  approach  for  managing  and  collaborating  on 
sparing  requirements  for  common  items.  This  group  meets... to  foster  the 
exchange  of  ideas  and  to  collaborate  on  cross-DOD  RBS  efforts. 
(Assistant  Secretary  of  Defense,  Logistics  and  Materiel  Readiness  2012) 

The  purpose  of  this  group  was  further  defined,  by  the  working  group  members,  to 
help  with  the  development  of: 

•  Criteria  for  choosing  RBS  solution(s)  that  will  move  into  production 

•  RBS  joint  operational  requirements 

•  Gaps  between  joint  requirements  and  current  capabilities  and  prioritization 
of  these  gaps  to  be  addressed  by  further  efforts 

•  Impacts  of  having  multiple  RBS  solutions  (Assistant  Secretary  of  Defense, 
Logistics  and  Materiel  Readiness  2012) 

This  research  defines  how  parts  sparing  is  currently  conducted  for  U.S.  Navy 
ships.  It  demonstrates  that  the  Navy  allows  multiple  sparing  systems,  each  designed  for  a 
weapon  system’s  specific  needs  to  support  weapon  system  readiness.  Based  on  this 
information,  the  team  determined  that  the  development  of  the  SCMM  system  would  be 
accepted  for  use  in  the  support  community,  that  it  is,  in  fact,  warranted  by  the  DOD 
Supply  Chain  Materiel  Management  Regulation,  DOD  4140.1 -R,  and  that  changes  to 
existing  RBS  models  could  be  initiated  in  collaboration  with  the  RBS  working. 

Different  systems  engineering  processes  were  investigated  to  determine  which 
one  would  be  the  most  suitable  for  use  in  the  project.  There  are  various  SE  development 
models  that  have  been  created  and  applied  to  system  development  projects.  These  models 
are  used  throughout  government  and  industry  and  are  based  on  one  of  three  influential 
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process  models:  waterfall  process  model,  spiral  process  model,  and  vee  process  model. 
More  specific  information  for  each  of  these  models  can  be  found  in  the  System 
Engineering  Process  section  in  the  Introduction  chapter.  Team  RSRP  determined  that  the 
waterfall  and  spiral  models  being  more  sequential  than  the  vee  model  made  them  difficult 
to  tailor  for  this  project  based  on  the  type  of  system  being  developed  and  the  personnel, 
time,  and  expertise  available.  Therefore,  the  vee  model  was  selected  to  permit  the 
systems  engineering  process  to  be  tailored  to  allow  for  the  necessary  steps  and  activities 
to  be  performed. 

Modeling  and  Simulation  is  considered  to  be  a  staple  in  any  field  of  engineering. 
According  to  the  International  Council  on  Systems  Engineering  (INCOSE), 

The  objective  of  modeling  and  simulation  is  to  obtain  information  about 
the  system  before  significant  resources  are  committed  to  its  design, 
development,  construction,  verification,  or  operation.  To  that  end, 
modeling  and  simulation  helps  generate  data  in  the  domain  of  the  analyst 
or  reviewer,  not  available  from  existing  sources,  in  a  manner  that  is 

affordable  and  timely  to  support  decision-making.  Adequate,  accurate,  and 
timely  models  and  simulations  inform  stakeholders  of  the  implications  of 
their  preferences,  provide  perspective  for  evaluating  alternatives,  and  build 
confidence  in  the  effects  that  an  implemented  system  will  produce. 
(INCOSE  2011,  150) 

The  team  researched  various  software  applications,  such  as  Vitech’s  CORE, 
Eclipse’s  Open  System  Engineering  Environment  (OSEE),  and  IBM’s  Rational  line  of 
products,  which  could  be  used  for  graphical  representations  of  DODAE  models  and 
requirements  analysis.  CORE  and  OSEE  are  purchasable  software  that  users  can  install 
but  IBM  Rational  is  more  of  a  service  that  is  provided  for  systems  engineering.  Both 
OSEE  and  CORE  offer  an  assortment  of  equivalent  tools.  However,  CORE  was  chosen 
due  to  its  availability  for  use  in  the  project  and  the  team’s  familiarity  with  the  software. 
Software  to  conduct  simulations  was  also  researched.  ExtendSim  and  Simulink  offer 
visualized  block  simulations  and  have  similar  capabilities.  ExtendSim  was  chosen  due  to 
the  team’s  familiarity  of  the  software  and  its  availability.  The  team  also  wanted  to 
simulate  an  output  report  of  the  SCMM  system.  The  manual  input  for  information  into 
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the  system  to  be  modeled  came  from  databases  that  provide  information  using  Microsoft 
Excel.  It  was  decided  to  maintain  this  format  and  not  look  into  outside  software  since 
Excel  was  available  for  use. 

B.  PROBLEM  STATEMENT 

An  initial  problem  statement  was  provided  to  the  team  by  the  sponsor.  The 
statement  was  general  and  required  refining.  In  order  to  refine  the  problem,  the  team 
conducted  research  and  requested  clarification  about  the  boundaries  of  the  system. 
During  an  interview  conducted  with  team  members  on  July  24,  2013,  Mr.  Howard  stated 
that  “Current  resupply  and  maintenance  points  will/have  two  different  paths  potentially. 
One  path  will  be  established  for  the  modular  equipment  or  systems  while  the  host 
platform  may/will  have  a  different  path.” 

After  additional  research  and  sponsor  feedback  to  clarify  the  initial  problem 
statement  and  background,  the  capstone  team  was  able  then  to  expand  on  the  knowledge 
of  the  topic  via  the  research  questions.  The  team  then  focused  on  the  problem 
background.  Through  an  iterative  process,  the  final  background  description  was  approved 
by  the  sponsor  on  August  30,  2013:  The  U.S.  Navy  has  begun  to  focus  acquisition 
strategies  to  incorporate  more  modular  and  flexible  designs  for  surface  ship  architecture 
in  an  effort  to  improve  procurement  and  life  cycle  costs  and  to  support  rapid  introduction 
of  capability.  Given  the  emphasis  on  modularity,  the  U.S.  Navy  is  also  placing 
importance  on  manning  requirements  that  are  optimized  to  support  modular/flexible 
constructs. 

The  problem  background  allowed  the  team  to  develop  the  finalized  problem 
statement  in  the  same  iterative  process  with  the  sponsor.  The  final  problem  statement  was 
approved  by  the  sponsor  on  August  30,  2013:  As  the  U.S.  Navy  drives  toward  modular 
and  flexible  designs,  the  currently  used  surface  Navy  SUM  models  do  not  support 
modular  or  flexible  design  ships.  These  ships  require  an  off-ship  maintenance  support 
structure  consisting  of  multiple  logistics  and  repair  nodes  due  to  shipboard  constraints 
including  manning,  space,  and  weight. 
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Working  with  the  sponsor,  the  team  then  identified  and  finalized  the  gap,  which  is 
the  difference  between  the  current  state  of  the  system  and  how  the  stakeholder  needs  the 
system  to  perform  and  operate.  The  sponsor  approved  the  gap  analysis  statement  on 
August  30,  2013:  The  systems/programs  currently  in  use  for  determining  spares 
allocations  do  not  provide  information  that  takes  into  account  the  ability  to  modify  ships 
rapidly  to  introduce  warfare  specific  capability  through  the  use  of  mission  modules  nor 
do  they  take  into  account  shipboard  constraints  including  manning,  space,  and  weight, 
which  impact  ships  ’  and  fleet’s  readiness  and  operational  availability. 

C.  STAKEHOLDER  ANALYSIS 

Having  defined  the  problem  and  identified  the  gap,  the  team  then  conducted  a 
stakeholder  analysis  to  determine  their  needs  and  develop  the  effective  need  statement. 
Stakeholders  are  those  people/entities  that  have  a  vested  interest  in  the  system,  problem 
and/or  solution.  A  stakeholder  analysis  was  performed  to  identify  the  people/entities  that 
are  germane  to  the  problem  and  also  those  who  interact  with  the  system.  This  analysis 
was  used  to  determine  the  stakeholders’  needs,  wants,  and  desires;  critical  assumptions 
and  constraints  were  also  identified.  To  begin,  the  stakeholders  for  the  SCM  problem 
were  identified.  The  team  established  all  the  applicable  stakeholders  through 
conversations  with  Mr.  Howard  during  the  problem  definition  process.  Once  the  team  had 
a  list  of  stakeholders,  their  needs  for  the  SCMM  system  were  identified,  again  with  the 
assistance  of  Mr.  Howard.  The  stakeholders  and  their  needs  are  recorded  in  Table  4.  It  is 
important  to  note  that  the  stakeholders  are  not  listed  in  any  particular  order.  Because  the 
stakeholders  were  not  readily  available,  the  need  statements  for  the  stakeholders  were 
approved  by  the  sponsor  and  not  by  the  individual  stakeholders  directly. 
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Stakeholder 

Need 

Sponsor 

Ensure  a  system  engineering  process  is  followed  to  develop  a 
sparing  model  that  can  be  developed  to  support  modular/flexible 
ships  and  their  support  facilities  to  have  the  required  parts  on-hand 
to  support  system  maintenance — preventive  and/or  corrective — 
within  manning,  space,  weight,  location,  and  cost/budget 
constraints. 

Maintenance 

Facilities 

Have  the  required  parts  on-hand  to  support  system  maintenance — 
preventive  and/or  corrective  within  manning,  space,  weight, 
location,  and  cost/budget  constraints. 

In-Service 
Engineering  Agent 
(ISEA) 

Know  what  parts  and  where  to  allocate  those  parts  to  allow  other 
entities  to  perform  maintenance — preventive  and/or  corrective 
within  manning,  space,  weight,  location,  and  cost/budget 
constraints. 

Program  Office 

Ensure  modular/flexible  ships  and  their  support  facilities  have  the 
required  parts  on-hand  to  support  system  maintenance — 
preventive  and/or  corrective — within  manning,  space,  weight, 
location,  and  cost/budget  constraints. 

Defense  Eogistics 
Agency  (DEA) 

Know  what  parts  and  where  to  allocate  those  parts  to  allow  other 
entities  to  perform  maintenance — preventive  and/or  corrective 
within  manning,  space,  weight,  location,  and  cost/budget 
constraints. 

Navy  Supply 
Systems  Command 
(NAVSUP) 

Know  what  parts  and  where  to  allocate  those  parts  to  allow  other 
entities  to  perform  maintenance — preventive  and/or  corrective 
within  manning,  space,  weight,  location,  and  cost/budget 
constraints. 

Sailor 

Have  the  required  parts  on-hand  to  support  system  maintenance — 
preventive  and/or  corrective. 

Eittoral  Combat 

Ship  Squadron 
(ECSRON)  / 

Type  Commander 
(TYCOM) 

Have  the  required  parts  on-hand  to  support  system  maintenance — 
preventive  and/or  corrective  within  manning,  space,  weight, 
location,  and  cost/budget  constraints. 

Table  4.  Stakeholder  Analysis  for  SCMM 


After  conducting  the  stakeholder  analysis,  the  team  finalized  the  effective  need. 
This  need  is  what  the  stakeholder/sponsor  needs  the  SCMM  system  to  do.  Through 
feedback  from  the  sponsor,  the  following  need  statement  was  developed  and  approved  on 
August  30,  2013:  “The  stakeholders  need  information  to  determine  sparing  of  parts  at 

31 


existing  and  multiple  supply  points  in  order  to  support  the  Navy’s  modular/flexible  ships 
within  the  constraints  of  manning,  space,  weight,  location,  and  cost/budget.” 

D.  FUNCTIONAL  ANALYSIS 

According  to  INCOSE,  a  function  is  a  characteristic  task,  action,  or  activity  that 
must  be  performed  to  achieve  a  desired  outcome.  Functional  analysis  is  an  examination 
of  a  defined  function  to  identify  all  the  sub-functions  necessary  to  accomplish  that 
function.  (INCOSE  2011)  The  functional  analysis  describes  what  the  system  must  do  at 
several  levels:  the  analysis  results  in  the  “whats” — what  the  system  must  do;  it  does  not 
identify  nor  result  in  the  “hows” — how  the  system  will  do  it  (Chapman,  Bahill  and 
Wymore  1992).  Buede  also  makes  this  quite  clear: 

The  very  strong  position  being  taken  here  is  that  the  input  and  output 
requirements  are  the  key  to  defining  the  needs  of  the  stakeholders  in  terms 
that  they  can  understand.  Stakeholders  in  each  phase  of  the  system’s  life 
cycle  can  relate  to  quantity,  quality,  and  timing  aspects  of  the  outputs 
delivered  by  the  system  under  question  and  the  ability  to  deal  with 
quantity,  quality,  and  timing  of  inputs.  The  engineers  of  the  system 
develop  the  system’s  functions  during  the  design  process.  This 
development  of  a  functional  architecture... is  a  very  valuable  means  for 
dealing  with  the  complexity  of  the  engineering  problem.  But  the 
stakeholders  should  not  care  a  whit  about  the  functions  being  performed 
by  the  system  as  long  as  they  are  happy  with  the  characteristics  of  the 
inputs  being  consumed  and  the  outputs  being  produced  by  the  system.  The 
concept  of  having  a  major  section  of  requirements  devoted  to  the  functions 
of  the  system  is  misguided  and  guaranteed  not  to  elicit  the  needs  of  the 
stakeholders.  (Buede  2000,  132) 

Focusing  on  the  “what”  rather  than  the  “how”  allows  for  innovative  solutions  by 
enlarging,  rather  than  limiting,  the  design  space. 

There  are  two  steps  in  the  functional  analysis:  the  functional  decomposition, 
derived  from  the  problem  statement  or  the  need  statement,  which  results  in  a  list  of 
functions  and  sub-functions;  and  the  organization  of  this  list  in  order  to  provide 
meaningful  information  (Chapman,  Bahill  and  Wymore  1992).  Either  a  hierarchy  of 
functions  diagram  or  a  FFBD  may  be  used  to  organize  the  list.  The  selection  of  either 
depends  on  whether  the  functions  flow  sequentially  or  not;  if  so,  then  a  FFBD  should  be 
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selected,  if  not,  a  hierarchy  diagram  should  be  used  (Chapman,  Bahill  and  Wymore 
1992).  It  is  necessarily  an  iterative  process  whereby  the  relationship  of  the  various 
functions  noted  in  the  decomposition  will  likely  influence  the  revision  of  the  hierarchy  or 
functional  flow  block  diagram  as  these  relationships  are  made  clearer  during  the 
decomposition  process  (Chapman,  Bahill  and  Wymore  1992). 

Team  RSRP  performed  a  functional  analysis,  in  conjunction  with  the  systems 
requirements  phase,  to  identify  the  critical  functions  of  the  system  after  the  problem  and 
need  statements  had  been  finalized.  For  convenience,  the  need  statement  is  restated,  as 
follows:  The  stakeholders  need  information  to  determine  sparing  of  parts  at  existing  and 
multiple  supply  points  in  order  to  support  the  Navy ’s  modular/flexible  ships  within  the 
constraints  of  manning,  space,  weight,  location,  and  cost/budget.  The  capabilities  of  the 
system  were  identified  with  the  sponsor  at  this  time,  also.  These  were  convert  (or 
process)  data  inputs  into  information  to  be  used  for  sparing  of  parts  at  various  locations 
based  on  the  use  case  scenarios  and  allow  the  users  to  conduct  sensitivity  analysis  based 
on  the  inputs  for  trade-off  analysis  for  cost,  operational  availability  (Ao),  personnel 
requirements,  weight,  and/or  space,  both  derived  from  the  need  statement.  Research  was 
conducted  during  the  needs  analysis  phase  to  include  stakeholder  “wants”  until  the 
system’s  functions  were  identified.  The  team  held  several  discussions  with  the  sponsor, 
Mr.  Howard,  to  ensure  that  the  required  functions  of  the  system  were  meeting  the 
stakeholders’  requirements,  which  were  being  developed  simultaneously. 

Based  on  the  need  statement,  and  in  order  to  better  determine  the  functions  of  the 
system,  use  case  scenarios  were  identified  with  the  sponsor,  Mr.  Howard.  Use  cases 
depict  how  the  system  will  be  used  by  the  user  to  achieve  an  objective  (Visual  Paradigm 
2011).  The  various  scenarios  that  the  SCMM  system  would  be  used  to  support  are  as 
follows: 

Support  of: 

•  Humanitarian  mission — single  ship 

•  Humanitarian  mission — multi-ship 

•  Multi-nodal,  single  ship  event  (includes  mission  package) 

•  Multi-nodal,  multi-ship  event  (includes  same  mission  packages) 
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•  Multi-nodal,  multi-mission  event  (includes  multiple  ships  and  mission 
packages) 

•  Test/single  event 

•  Single  ship  system 

•  Multiple  ship  systems 

•  Single  mission  module 

•  Multiple  mission  modules 

•  Single  mission  package  (no  hull,  mechanical,  and  electrical  [HM&E]) 

•  Multiple  mission  packages  (no  HM&E) 

Eor  the  SCMM  system,  development  of  the  use  cases  entailed  determining  the 
operational  sequence  of  system  use  based  on  a  specific  user  scenario  with  the  required 
user  inputs  to  obtain  a  required  output.  The  use  case  for  the  “support  single  mission 
module”  scenario  was  partially  developed  using  CORE  based  on  the  operational 
activities,  and  is  depicted  in  Eigure  6.  The  user’s  objective  is  to  support  a  single  mission 
module  onboard  an  operational  ship  to  meet  Ao  and  cost  requirements.  The  user  would 
perform  the  following  actions  with  the  SCMM  system  in  order  to  support  this  objective: 

•  Eaunch  system 

•  Enter  login  information 

•  Execute  login 

•  Enter  input/selection 

•  Execute  system  (for  system  to  perform) 

•  Assess  results  (of  output) 

•  Eog  off 

Based  on  the  assessment  of  the  output,  the  user  would  allocate  spare  parts  to  multi-nodal 
locations  to  support  a  single  mission  module.  The  figure  also  depicts  the  generalized 
inputs  required  to  use  and  obtain  the  necessary  information  from  the  system;  and  it  also 
depicts  the  queries  from  the  various  users;  these  are  depicted  as  the  small  round-edge 
boxes  that  have  arrows  towards  the  “D — Enter  Inputs/Selection”  box 
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Figure  6.  Use  Case  for  “Support  Single  Mission  Module”  Scenario 


The  system  requires  inputs  to  process  into  outputs  to  support  the  use  case 
scenarios.  Inputs,  in  this  case,  are  the  user  entered  or  selected  inputs  and  the  data  pushed 
from  the  various  databases  that  have  the  needed  information  for  the  system  to  transform 
them  into  the  required  outputs.  The  analysis  of  the  inputs  and  outputs  of  the  system  are 
further  described  and  illustrated  in  the  System  Boundaries  section  of  the  System 
Requirements  chapter. 

It  was  very  important  to  identify  and  organize  the  functions  and  sub-functions  in  a 
meaningful  way,  allowing  for  an  analysis  of  alternatives  to  be  conducted  during  the 
conceptual  design  phase  (Chapman,  Bahill  and  Wymore  1992).  It  also  helped  to  ensure 
that  the  design  alternatives  would  meet  the  needs  of  the  stakeholders  (Chapman,  Bahill 
and  Wymore  1992). 

The  functional  analysis  continued  by  deriving  the  system’s  top  level  functions 
based  on  the  capabilities  of  the  system  and  the  use  cases.  The  top  level  functions  can  be 
seen  in  the  FFBD  as  shown  in  Figure  7  (developed  in  CORE,  as  are  all  subsequent 
figures  in  this  section).  These  are: 

•  Enable  graphic  user  interface 

•  Receive  data 

•  Process  data 

•  Provide  output 
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•  Maintain  system 

•  Secure  system 

“Maintain  system”  and  “secure  system”  are  performed  concurrently  with  the  other 
functions,  as  shown  by  the  “And”  in  the  circles.  The  system  functions  are  depicted  by  the 
rectangular  numbered  boxes. 


Figure  7.  SCMM  System  Top-Level  Functional  Flow  Block  Diagram 


These  top-level  functions  were  further  decomposed  into  the  sub-functions 
supporting  them.  These  can  be  seen  in  Figure  8  and  are  shown  in  segments  in  subsequent 
figures  for  readability. 

Following  is  a  description  of  this  figure  that  also  applies  to  the  subsequent 
function  figures.  The  rectangular  boxes  depict  the  functions  and  sub-functions  of  the 
system.  Each  has  arrows  that  show  the  flow  of  the  functions.  The  items  found  in  circles 
denote  the  following: 

•  “AND”:  concurrent  function 

•  “LP”:  loop;  repeated  until  a  specific  objective  has  been  achieved 

•  “LE”:  loop  end;  the  end  of  the  loop 

•  “OR”:  does  otherwise;  used  to  link  two  or  more  alternatives 

This  analysis  also  yielded  the  SV-4 — system  functionality  diagram — that  is  found 
in  the  DODAF  views  section  of  the  System  Architecture  chapter.  The  only  difference 
between  the  two  is  that  the  SV-4  describes  the  resources  that  flow  between  the  functions. 
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Figure  8.  SCMM  System  Functional  Flow  Block  Diagram 
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The  complete  listing  of  the  functions  and  the  functional  requirements  are  shown 
in  Table  5. 


Requirements  and  Functions 

Number 

Requirement 

Number 

Function 

1.4 

System 

Functionality/Functional 

Requirements 

1.4.1 

The  system  shall  enable  a 
graphical  user  interface  (GUI). 

1 

Enable  Graphic  User 

Interface  (GUI) 

1.4.1. 1 

The  system  shall  display  a 
login  screen  in  no  more  than  1 
minute. 

1.1 

Display  Log-in  Screen 

1.4.1. 1.1 

The  system  shall  accept  a  user 
name  and  password  in  no  more 
than  5  seconds. 

1.1.1 

Accept  User  Name  and 
Password 

1.4.1.2 

The  system  shall  perform  a 
login  credential  security 
verification  in  no  more  than  2 
seconds. 

1.2 

Perform  Login  Credential 
Security  Verification 

1.4.1.2.1 

The  system  shall  invalidate  a 
login  due  to  an  incorrect 
password  entry  in  no  more  than 

1  second. 

1.2.1 

Invalidate  Password 

1.4.1.2.2 

The  system  shall  invalidate  a 
login  due  to  an  incorrect 
username  entry  in  no  more  than 

1  second. 

1.2.2 

Invalidate  User  Name 

1.4.1.2.3 

The  system  shall  validate  a 
login  due  to  a  correct  username 
and  password  entry  in  no  more 
than  1  second. 

1.2.3 

Validate  Username  and 
Password 

1.4.1.3 

The  system  shall  display  a 
graphic  user  interface  in  no 
more  than  5  seconds. 

1.3 

Display  GUI 

1.4. 1.4 

The  system  shall  enable  data 
entry/selection  fields  in  no 
more  than  5  seconds. 

1.4 

Enable  data  entry/selection 
fields 

1.4.2 

The  system  shall  receive  data. 

2 

Receive  Data 

1.4.2.1 

The  system  shall  accept  a 
user’s  input/selection  in  no 
more  than  2  seconds. 

2.1 

Accept  User  Input/Selected 
Data 
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Requirements  and  Functions 

Number 

Requirement 

Number 

Function 

1.4.2.1.1 

The  system  shall  verify  the 
user’s  inputs/selected  data  in  no 
more  than  2  seconds. 

2.1.1 

Verify  User  Input/Selected 
Data 

1.4.2.1.1.1 

The  system  shall  invalidate 
incorrect  user  inputs  in  no  more 
than  2  seconds 

2.1. 1.1 

Invalidate  User  Inputs 

1.4.2.1.1.2 

The  system  shall  validate 
correct  user  inputs  in  no  more 
than  2  seconds. 

2.1. 1.2 

Validate  User  Inputs 

1.4.2.2 

The  system  shall  accept  data 
from  external  databases  in  no 
more  than  1  hour. 

2.2 

Accept  Data  from  External 
Databases 

1.4.2.2.1 

The  system  shall  verify  data 
integrity 

(complete/correct/does  not 
contain  errors)  in  no  more  than 
30  minutes. 

2.2.1 

Verify  Data  Integrity 
(Complete/Correct/Does 

Not  Contain  Errors) 

1.4.2.2.1.1 

The  system  shall  invalidate 
incorrect  database  data  in  no 
more  than  30  minutes. 

2.2.1. 1 

Invalidate  Database  Data 

1.4.2.2.1.2 

The  system  shall  validate 
correct  external  database  data 
in  no  more  than  30  minutes. 

2.2.1.2 

Validate  External  Database 
Data 

1.4.2.2.2 

The  system  shall  integrate  the 
data  into  a  repository  in  no 
more  than  15  minutes. 

2.2.2 

Integrate  the  data  into 
repository 

1.4.2.2.3 

The  system  shall  save  data  in  a 
system  repository  in  no  more 
than  15  minutes. 

2.2.3 

Save  Data  in  System 
Repository 

1.4.3 

The  system  shall  process  data. 

3 

Data  Processing 

1.4.3.1 

The  system  shall  process 
requests  in  no  more  than  1 
second. 

3.1 

Process  Request 

1.4.3.2 

The  system  shall  execute 
queries  in  no  more  than  1 
second. 

3.2 

Execute  Query 

1.4.3.3 

The  system  shall  verify  query 
requirements  are  being  met  in 
no  more  than  1  second. 

3.3 

Verify  Query  Requirements 
Are  Being  Met 

1.4.3.3.1 

The  system  shall  invalidate 
incomplete/incorrect  queries  in 
no  more  than  1  second. 

3.3.1 

Invalidate  Query 
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Requirements  and  Functions 

Number 

Requirement 

Number 

Function 

1.4.3.3.2 

The  system  shall  validate 
complete/correct  queries  in  no 
more  than  1  second. 

3.3.2 

Validate  Query 

1.4.3.4 

The  system  shall  obtain  filtered 
data  from  the  repository  in  no 
more  than  2  minutes. 

3.4 

Obtain  Filtered  Data  From 
Repository 

1.4.3.5 

The  system  shall  perform 
sparing  analysis  in  no  more 
than  5  minutes. 

3.5 

Perform  Sparing  Analysis 

1.4.4 

The  system  shall  provide 
outputs. 

4 

Provide  Output 

1.4.4.1 

The  system  shall  display 
sparing  results  (graphical 
output  based  on  user’s  query) 
in  no  more  than  1  second. 

4.1 

Display  Sparing  Results 
(Graphical  Output  Based  on 
User’s  Query) 

1.4.4.1.1 

The  system  shall  allow  the  user 
to  save  sparing  results  in  no 
more  than  1  second. 

4.1.1 

Save  Sparing  Results 

1.4.4.1.2 

The  system  shall  allow  the  user 
to  print  sparing  results  in  no 
more  than  1  second. 

4.1.2 

Print  Sparing  Results 

1.4.4.1.3 

The  system  shall  allow  the  user 
to  perform  sensitivity  analysis 
in  no  more  than  1  second. 

4.1.3 

Perform  Sensitivity  Analysis 

1.4.4.1.4 

The  system  shall  allow  the  user 
to  delete  results  in  no  more 
than  1  second. 

4.1.4 

Delete  Results 

1.4.5 

The  system  shall  provide  self¬ 
maintenance  through  a  series  of 
checks  and  display  the 
information  to  the  user. 

5 

Maintain  System 

1.4.5. 1 

The  system  shall  execute  self¬ 
checks  in  no  more  than  2 
seconds. 

5.1 

Execute  System  Self  Check 

1.4.5. 1.1 

The  system  shall  execute  a 
repository  check  in  no  more 
than  0.5  seconds. 

5.1.1 

Execute  Repository  Check 

1.4.5. 1.2 

The  system  shall  execute  an 
interface  check  in  no  more  than 

1  second. 

5.1.2 

Execute  Interface  Check 
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Requirements  and  Functions 

Number 

Requirement 

Number 

Function 

1.4.5. 1.2.1 

The  system  shall  execute  an 
interface  check  of  the  system 
side  in  no  more  than  0.5 
seconds. 

5. 1.2.1 

Execute  System  Side  Check 
of  Interface 

1.4.5. 1.2.2 

The  system  shall  execute  an 
interface  check  of  the  external 
databases  in  no  more  than  0.5 
seconds. 

5. 1.2.2 

Execute  External  Database 
Check  of  Interface 

1.4.5.1.2.2.1 

The  system  shall  display  a 
status  of  the  external  databases 
in  no  more  than  0.5  seconds. 

5.1.2.2.1 

Display  External  Database 
Status 

1.4.5. 1.3 

The  system  shall  execute  a 
processes  check  in  no  more 
than  0.5  seconds. 

5.1.3 

Execute  Processes  Check 

1.4.5.2 

The  system  shall  provide  the 
user  with  a  maintenance  history 
in  no  more  than  1  second. 

5.2 

Provide  Maintenance 

History 

1.4.5.2.1 

The  system  shall  display  the 
time  and  date  of  the  last 
database  data  download  in  no 
more  than  1  second. 

5.2.1 

Display  Time/Date  of  East 
Data  Download 

1.4.5.2.2 

The  system  shall  display  the 
time  and  date  of  the  last  login 
in  no  more  than  1  second. 

5.2.2 

Display  East  Eogin 
Information 

1.4.6 

The  system  shall  secure  itself. 

6 

Secure  System 

1.4.6.1 

The  system  shall  comply  with 
DOD  and  DoN  Information 
Assurance  (lA)  policies  and 
procedures. 

6.1 

Ensure  Information 

Assurance  Compliance 

1.4.6.2 

The  system  shall  secure  the 

GUI  continuously. 

6.2 

Secure  the  GUI 

1.4.6.3 

The  system  shall  secure  the 
log-in  process  when  in  login 
screen. 

6.3 

Secure  Eogin  Process 

1.4.6.4 

The  system  shall  secure  the 
repository  continuously. 

6.4 

Secure  Repository 

1.4.6.5 

The  system  shall  secure  the 
interfaces  with  the  external 
databases  continuously. 

6.5 

Secure  the  Interfaces  with 
External  Databases 

Table  5.  Functions  and  Functional  Requirements 
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Figure  9  displays  the  functions  and  sub-functions  of  function  1:  enable  graphic  user  interface. 
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Figure  9.  SCMM  System  Function  1 :  Enable  Graphic  User  Interface 


42 


Figure  10  displays  the  functions  and  sub-functions  of  function  2:  receive  data. 


Figure  10.  SCMM  System  Function  2:  Receive  Data 
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Figure  11  displays  the  functions  and  sub-functions  of  function  3:  process  data. 
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Figure  11.  SCMM  System  Function  3:  Process  Data 


44 


Figure  12  displays  the  functions  and  sub-functions  of  function  4:  provide  output. 
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Figure  12.  SCMM  System  Function  4:  Provide  Output 
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Figure  13  displays  the  functions  and  sub-functions  of  function  5:  maintain  system. 


Figure  13.  SCMM  System  Function  5:  Maintain  System 
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Figure  14  displays  the  funetions  and  sub-funetions  of  funetion  6:  seeure  system. 


Figure  14.  SCMM  System  Funetion  6:  Seeure  System 


A  hierarehy  bloek  diagram  (HBD)  was  also  developed  using  the  CORE  tool.  This 
diagram  was  developed  to  model  the  hierarehy  of  funetions  and  sub-funetions.  Figure  15 
shows  the  top-level  funetions  of  the  SCMM  system.  Functions  1-6  can  be  seen  in  more 
detail  in  the  succeeding  figures. 


47 


Figure  15.  SCMM  System  Top-Level  Functions  Hierarchy  Block  Diagram 


Figure  16  depicts  the  HBD  of  function  1:  enable  graphic  user  interface  (GUI). 


Figure  16.  SCMM  Function  1:  Enable  Graphic  User  Interface  Hierarchy  Block 

Diagram 


Figure  17  depicts  the  HBD  of  function  2:  receive  data 
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Figure  17.  SCMM  System  Function  2:  Receive  Data  Hierarchy  Block  Diagram 


Figure  18  depicts  the  HBD  of  function  3:  process  data. 
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Figure  18.  SCMM  System  Function  3:  Process  Data  Hierarchy  Block  Diagram 
Figure  19  depicts  the  HBD  of  function  4:  provide  output. 
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Figure  19.  SCMM  System  Function  4:  Provide  Output  Hierarchy  Block  Diagram 


Figure  20  depicts  the  HBD  of  function  5 :  Maintain  System 
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Figure  20.  SCMM  System  Function  5:  Maintain  System  Hierarchy  Block  Diagram 


Figure  21  depicts  the  HBD  of  function  6:  secure  system. 


Figure  21.  SCMM  System  Function  6:  Secure  System  Hierarchy  Block  Diagram 
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A  matrix  listing  each  input  and  output  (defined  as  an  “item”  in  CORE)  allocated 
to  a  specific  function  was  created  with  the  SCMM  system’s  information  resident  in 


CORE.  The  inputs  and  outputs  allocated  to  the  functions  can  be  seen  in  Table  6. 


Eunction  Input  Output  Table 

Items  (inputs  or  outputs) 

Input  to 

Output  to 

Activated  Data  Entry 

Eields 

Eunction  2  Receive  Data 

Eunction  I  Enable 

Graphic  User  Interface 
(GUI) 

Activated  Maintenance 
Access 

Eunction  5  Maintain  System 

Eunction  I  Enable 

Graphic  User  Interface 
(GUI) 

Assigned  Regional 
Maintenance  Center 
(RMC) 

Eunction  2  Receive  Data 

Budget 

Eunction  2  Receive  Data 

Database  Side  Interface 
Status 

Eunction  5  Maintain 

System 

DEA  Distribution 

Centers 

Eunction  2  Receive  Data 

Duration  of  operation(s) 

Eunction  2  Receive  Data 

Elect  area  of  operation 

Eunction  2  Receive  Data 

Elect  Eogistics  Centers 
(formerly  EISCs:  Elect 
and  Industrial  Support 
Centers) 

Eunction  2  Receive  Data 

Graphical  Output 

Eunction  4  Provide  Output 

GUI 

Eunction  I  Enable 

Graphic  User  Interface 
(GUI) 

Maintenance  facility 
locations(s) 

Eunction  2  Receive  Data 

Maintenance  History 

Eunction  5  Maintain 

System 

Mission  module(s) 

Eunction  2  Receive  Data 

Mission  module(s)  Ao  to 
support  the 

mission/multi-mission 

Eunction  2  Receive  Data 

Mission  Module(s) 
availability  requirement 
(Ao,  etc.) 

Eunction  2  Receive  Data 

52 


Function  Input  Output  Table 

Items  (inputs  or  outputs) 

Input  to 

Output  to 

Mission  module(s) 
configuration  Allowance 
Parts  List 
( APLs )/ Allow  ance 
Equipage  List  (AELs) 

Function  2  Receive  Data 

Mission  module(s) 
container  available  space 
/  dimensions  allowance 
for  parts 

Function  2  Receive  Data 

Mission  module(s) 
container  available 
weight  allowance  for 
parts 

Function  2  Receive  Data 

Mission  package 
(man.)(e.g.,  SUW,  ASW, 
MCM,  humanitarian) 

Function  2  Receive  Data 

Part  cage  code(s) 

Function  2  Receive  Data 

Part  cost(s) 

Function  2  Receive  Data 

Part  criticality 

Function  2  Receive  Data 

Part  dimensions 

Function  2  Receive  Data 

Part  estimated  shipping 
time 

Function  2  Receive  Data 

Part  failure  rate/mean 
time  between  failure 
(MTBF) 

Function  2  Receive  Data 

Part  hazardous  material 
(HAZMAT)  information 

Function  2  Receive  Data 

Part  item  manager  point 
of  contact  (POC) 

Function  2  Receive  Data 

Part  maintenance  code(s) 

Function  2  Receive  Data 

Part  nomenclature(s) 

Function  2  Receive  Data 

Part  national  stock 
numbers  (NSNs)s 

Function  2  Receive  Data 

Part  number(s) 

Function  2  Receive  Data 

Part  weight 

Function  2  Receive  Data 

Planned  changes  to 
mission  module’s 
configuration/dates  for 
changes 

Function  2  Receive  Data 
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Function  Input  Output  Table 

Items  (inputs  or  outputs) 

Input  to 

Output  to 

Planned  changes  to  ship’s 
configuration/dates  for 
changes 

Function  2  Receive  Data 

Processes  Status 

Function  5  Maintain 

System 

Projected  Ao  of  ship(s) 

Function  4  Provide  Output 

Function  3  Process  Data 

Repository  Data 

Function  3  Process  Data 

Function  2  Receive  Data 

Repository  Status 

Function  5  Maintain 

System 

Sensitivity  Analysis  -  Ao 

Function  2  Receive  Data 

Function  4  Provide  Output 

Sensitivity  Analysis  - 
Budget 

Function  2  Receive  Data 

Function  4  Provide  Output 

Sensitivity  Analysis  - 
Space 

Function  2  Receive  Data 

Function  4  Provide  Output 

Sensitivity  Analysis  - 
Weight 

Function  2  Receive  Data 

Function  4  Provide  Output 

Ship  hull  number(s) 

(man) 

Function  2  Receive  Data 

Ship  seaframe  system(s) 

Function  2  Receive  Data 

Ship(s)  availability 
requirement  (Ao) 

Function  2  Receive  Data 

Ship(s)  available  space  / 
dimensions  allowance  for 
parts. 

Function  2  Receive  Data 

Ship(s)  available  weight 
allowance  for  parts. 

Function  2  Receive  Data 

Ship(s)  configuration 
(APLs/AELs) 

Function  2  Receive  Data 

Ship(s)  system 

Function  2  Receive  Data 

Spares  allocation  at  land- 
based  maintenance 
facilities 

Function  4  Provide  Output 

Function  3  Process  Data 

Spares  allocation  at 
OCONUS  warehouse 
locations 

Function  4  Provide  Output 

Function  3  Process  Data 

Spares  allocation  for 
mission  module(s) 
container(s) 

Function  4  Provide  Output 

Function  3  Process  Data 

Spares  allocation  on  ship 

Function  4  Provide  Output 

Function  3  Process  Data 

Summary  of  inputs 

Function  4  Provide  Output 

Function  3  Process  Data 
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Function  Input  Output  Table 

Items  (inputs  or  outputs) 

Input  to 

Output  to 

System  Side  Interface 
Status 

Function  5  Maintain 

System 

System  status 

Function  5  Maintain 

System 

Total  cost  of  parts 
allocated 

Function  4  Provide  Output 

Function  3  Process  Data 

Total  ship  Ao  by  mission 
(does  not  include 

HM&E) 

Function  2  Receive  Data 

Total  ship  Ao  by  mission 
(includes  HM&E) 

Function  2  Receive  Data 

Total  space  of  mission 
module(s)  container(s) 
spares 

Function  4  Provide  Output 

Function  3  Process  Data 

Total  space  of  shipboard 
spares 

Function  4  Provide  Output 

Function  3  Process  Data 

Total  weight  of  mission 
module(s)  container(s) 
spares 

Function  4  Provide  Output 

Function  3  Process  Data 

Total  weight  of  shipboard 
spares 

Function  4  Provide  Output 

Function  3  Process  Data 

User  Inputs 

Function  3  Process  Data 

Function  2  Receive  Data 

User  Name  and  Password 

Function  I  Enable  Graphic  User 
Interface  (GUI) 

Table  6.  SCMM  System — Input  and  Output  Function  Allocation 


E.  SUMMARY 

The  first  phase  of  the  team’s  tailored  SE  process  was  to  analyze  the  stakeholder 
needs.  The  first  step  in  this  process  of  needs  identification  was  defining  the  problem 
definition,  which  was  accomplished  by  conducting  interviews  with  the  sponsor  resulting 
in  the  agreed  upon  problem  background:  The  U.S.  Navy  has  begun  to  focus  acquisition 
strategies  to  incorporate  more  modular  and  flexible  designs  for  surface  ship  architecture 
in  an  effort  to  improve  procurement  and  life  cycle  costs  and  to  support  rapid  introduction 
of  capability.  Given  the  emphasis  on  modularity,  the  Navy  is  also  placing  importance  on 
manning  requirements  that  are  optimized  to  support  modular/flexible  constructs. 
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Team  RSRP  conducted  a  literature  review  of  available  published  materials, 
including  scholarly  articles,  journals,  and  reports  to  research  and  substantiate  the 
challenges  of  the  current  supply  chain  and  to  identify  relevant  terms  included  in  the 
problem  statement.  The  team  then  developed  questions  to  focus  the  research  to  areas 
related  to  modular  or  flexible  design  ships.  The  research  questions  were  posed  in 
subsequent  interviews  to  the  sponsor  to  understand  the  organizations  that  are  involved 
with  ship  sustainment  operations  and  would  be  affected  by  the  development  of  a  new 
SCM  model  supporting  modular  ship  classes.  Through  an  iterative  process  of  interviews 
with  the  sponsor  and  topic  research,  the  final  problem  statement  was  defined  and 
approved  by  the  sponsor  on  August  30,  2013:  As  the  U.S.  Navy  drives  toward  modular 
and  flexible  designs,  the  currently  used  surface  Navy  SCM  models  do  not  support 
modular  or  flexible  design  ships.  These  ships  require  an  off-ship  maintenance  support 
structure  consisting  of  multiple  logistics  and  repair  nodes  due  to  shipboard  constraints 
including  manning,  space,  and  weight. 

Upon  final  problem  statement  definition,  the  project  team  finalized  the 
identification  of  the  relevant  stakeholders  for  the  SCMM  system,  and  established  the 
individual  stakeholder  needs  for  the  system.  The  stakeholders  were  identified  to  be: 
project  sponsor,  maintenance  facilities,  ISEA,  program  office,  DLA,  NAVSUP,  the 
sailor,  and  LCSRON  TYCOM.  Through  analysis  of  the  stakeholder  needs  the  team 
finalized  the  overall  system  effective  need  statement:  The  stakeholders  need  information 
to  determine  sparing  of  parts  at  existing  and  multiple  supply  points  in  order  to  support 
the  Navy’s  modular/flexible  ships  within  the  constraints  of  manning,  space,  weight, 
location,  and  cost/budget.  This  was  confirmed  by  the  sponsor  on  August  30,  2013. 

Team  RSRP  began  the  functional  analysis  upon  establishment  of  the  needs 
statement  by  determining  what  the  system  must  do.  The  functional  analysis  was 
accomplished  by  defining  several  use  case  scenarios  which  identified  the  functions  of  the 
system  and  the  necessary  inputs  and  outputs  of  the  system.  These  were  approved  by  the 
sponsor  and  would  be  utilized  during  the  design  phase  of  the  project.  A  use  case,  FFBDs, 
HBDs,  a  table  listing  the  functions  and  functional  requirements  were  developed  during 
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this  phase,  and  a  matrix  allocating  the  inputs  and  outputs  to  functions  were  created  during 
the  functional  analysis  (in  conjunction  with  the  requirements  development  phase). 
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III.  SYSTEM  REQUIREMENTS 


To  enable  commencement  of  the  conceptual  design  of  a  system  to  satisfy  the 
determined  capability  gaps,  a  complete  and  iterative  analysis  of  system  requirements  was 
embarked  upon.  An  investigation  of  the  existing  system  structure  and  interoperability 
requirements  between  designated  stakeholders  was  documented  to  allow  for 
implementation  of  the  developed  system.  Model  based  systems  engineering  was 
performed  to  show  requirements  traceability  and  to  define  system  boundaries.  A 
requirements  analysis  was  performed  based  on  the  stakeholders’  originating  requirement 
(need  statement),  which  was  then  used  by  the  team  to  develop  derived  requirements  to 
include:  input/output  requirements,  technology  and  suitability  requirements,  system 
trade-off  requirements,  and  system  qualification  requirements.  The  development  and 
confirmation  of  system  requirements  allowed  the  system  architecture  and  conceptual 
design  phases  to  continue. 

A.  SYSTEM  MODELING 

The  system’s  architecture,  functions,  requirements,  and  various  DODAF  views 
were  modeled  in  Vitech’s  CORE.  CORE  is  explained  in  detail  in  the  System  Modeling 
section  of  Chapter  VI  Modeling  and  Simulation. 

A  baseline  was  created  in  CORE  that  allowed  the  team  to  maintain  system 
architecture  validity  throughout  refinement  and  discussions  with  the  sponsor.  The 
baseline  was  the  initial  set  of  data  that  the  team  developed  to  model  the  system.  This  data 
included  the  initial  functions,  requirements,  and  views  based  on  early  discussion  with  the 
sponsor.  Modeling  a  baseline  of  the  system  was  important  because  it  provided  a  detailed 
view  of  the  system,  which  was  used  for  future  meetings  with  the  sponsor  to  elicit 
feedback.  All  models  in  CORE  are  built  around  and  linked  to  a  central  repository  (Vitech 
2013).  This  allowed  for  a  change  that  was  made  in  one  diagram  to  be  reflected  across  all 
diagrams  (Vitech  2013).  These  diagrams  were  not  only  useful  in  creating  DODAE 
deliverables,  but  also  they  were  used  to  effectively  communicate  the  architecture  to  the 
team  and  sponsor. 
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B.  SYSTEM  BOUNDARIES 


The  system  boundary  determines  whether  something  belongs  in  the  system  or  not; 
it  is  used  to  separate  the  system  from  its  environment  while  the  system  is  connected  to  the 
environment  by  the  inputs  and  outputs  that  cross  the  system  boundary.  When  defining  the 
problem,  the  team  used  system  models  /  diagrams  to  determine  what  entities  would  be 
interfacing  and  influencing  the  system.  The  team  first  developed  an  ICOM  diagram  to 
scope  and  bound  the  problem.  By  scoping  the  problem  one  ensures  that  it  is  broad  enough 
to  contain  all  relevant  matters;  by  bounding  the  problem,  one  defines  the  limits  so  that  the 
problem  is  controllable  (Sage  and  Armstrong  2000).  ICOM  diagrams  also  allow  the 
analysis  of  the  inputs  and  outputs  while  sequestering  the  system  while  the  form  and 
function  of  the  system  remain  undefined  during  this  process  (Sage  and  Armstrong  2000). 

The  team  created  a  high-level  ICOM  diagram,  shown  in  Figure  22.  A  function 
box  representing  the  SCMM  was  used  to  establish  the  context  of  the  system  the  team 
modeled.  Four  types  of  information  lines  were  drawn  into  or  out  of  this  function  box. 
Inputs  are  shown  as  arrows  entering  the  left  side  of  the  function  box.  The  SCMM 
system’s  inputs  were  the  data  from  the  various  databases  that  provide  information  to  the 
system  as  well  as  user  entered  inputs.  Outputs  are  shown  as  exiting  arrows  on  the  right 
side  of  the  box.  For  the  SCMM,  the  outputs  were  the  supply  information  for  the 
stakeholders’  use.  Controls/constraints  are  displayed  as  arrows  entering  the  top  of  the 
box.  Controls  and/or  constraints  are  a  form  of  input,  but  are  used  to  direct  the  activity  in 
the  process.  The  SCMM  system’s  controls  and  constraints  were  initially  identified  as 
economic,  environmental,  political,  sociological,  and  technical.  Mechanisms  are 
displayed  as  arrows  entering  from  the  bottom  of  the  box.  Mechanisms  are  the  resources 
and  tools  that  are  required  for  realizing  the  function  including  operating  personnel, 
maintenance  support  personnel,  and  machines/tools  such  as  computers. 
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Figure  22. 


SCMM  System  High-Level  ICOM  Diagram 


A  detailed  ICOM  diagram  based  on  specific  inputs,  outputs,  controls/constraints, 
and  mechanisms  was  then  developed  in  conjunction  with  the  sponsor.  The  information 
used  in  this  diagram  is  shown  in  Table  7.  The  inputs,  outputs,  controls/constraints,  and 
mechanisms  are  independent  of  each  other  within  the  table. 


Inputs 

Outputs 

Controls/Constraints 

Mechanisms 

Assigned  RMC 

Database  Side 
Interface  Status 

The  system  shall  interface 
with  NDE:  AMPS 

Computer 

Resources 

Budget 

Maintenance 

History 

The  system  shall  interface 
with  NDE:  CDMD-OA 

User:  DEA 

DLA  Distribution 
Centers 

Processes  Status 

The  system  shall  interface 
with  NAVSUP  ERP. 

User:  ISEA 

Duration  of 
operation(s)  per 
applicable  entry 

Projected  Ao  of 
ship(s) 

The  system  shall  interface 
with  user  host  platform(s). 

User:  MPSE 
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Inputs 

Outputs 

Controls/Constraints 

Mechanisms 

Fleet  area  of 
operation 

Repository  Status 

The  system  shall  be 
interoperable  with  DOD  GIG. 

User: 

NAVSUP 

Fleet  Logistics 

Centers  (formerly 
FISCs:  Fleet  and 
Industrial  Support 
Centers) 

Sensitivity 
Analysis — Ao 

The  system  shall  comply  with 
DOD  and  DoN  Information 
Assurance  (lA)  policies  and 
procedures. 

Maintenance  facility 
locations(s) 

Sensitivity 
Analysis — 

Budget 

The  system  shall  be  hosted  on 
a  DOD  authorized  platform. 

Mission  module(s) 

Sensitivity 
Analysis — Space 

The  system  shall  conform  to  a 
modular  open  systems 
approach  (MOSA). 

Mission  Module(s) 
availability 
requirement  (Ao) 

Sensitivity 
Analysis — 

Weight 

The  system  shall  conform  to 
MOSA  by  adapting  to 
evolving  requirements. 

Mission  module(s) 

configuration 

(APLs/AELs) 

Spares  allocation 
at  land-based 
maintenance 
facilities 

The  system  shall  conform  to 
MOSA  by  enhancing  access 
to  cutting  edge  technologies 
and  products. 

Mission  module(s) 
container  available 
space  /  dimensions 
allowance  for  parts 

Spares  allocation 
at  OCONUS 
warehouse 
locations 

The  system  shall  conform  to 
MOSA  by  enhancing 
commonality  and  reuse  of 
components  among  systems. 

Mission  module(s) 
container  available 
weight  allowance  for 
parts 

Spares  allocation 
for  mission 
module(s) 
container(s) 

The  system  shall  conform  to 
MOSA  by  enhancing  life- 
cycle  supportability. 

Mission  package 
(man.)(e.g.,  SUW, 
ASW,  MCM, 
humanitarian) 

Spares  allocation 
on  ship 

The  system  shall  conform  to 
MOSA  by  ensuring  that  the 
system  will  be  fully 
interoperable  with  all  the 
systems  with  which  it  must 
interface  without  major 
modification  of  existing 
components. 

Part  cage  code(s) 

Summary  of 
inputs 

The  system  shall  conform  to 
MOSA  by  facilitating  systems 
integration. 

Part  cost(s) 

System  Side 
Interface  Status 

The  system  shall  conform  to 
MOSA  by  mitigating  the  risk 
associated  with  technology 
obsolescence. 
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Inputs 

Outputs 

Controls/Constraints 

Mechanisms 

Part  criticality 

System  status 

The  system  shall  conform  to 
MOSA  by  mitigating  the  risk 
of  a  single  source  of  supply 
over  the  life  of  the  system. 

Part  dimensions 

Total  cost  of 
parts  allocated 

The  system  shall  conform  to 
MOSA  by  reducing  the 
development  cycle  time. 

Part  estimated 
shipping  time 

Total  space  of 

mission 

module(s) 

container(s) 

spares 

The  system  shall  conform  to 
MOSA  by  reducing  total 
lifecycle  cost. 

Part  failure 
rate/MTBF 

Total  space  of 
shipboard  spares 

The  system  shall  comply  with 
DOD  human  system 
integration 

standards/specifications . 

Part  HAZMAT 
information 

Total  weight  of 

mission 

module(s) 

container(s) 

spares 

Part  item  manager 
POC 

Total  weight  of 
shipboard  spares 

Part  maintenance 
code(s) 

Part  nomenclature(s) 

Part  NSN(s) 

Part  number(s) 

Part  weight 

Planned  changes  to 
mission  module’s 
configuration/dates 
for  changes 

Planned  changes  to 
ship’s 

configuration/dates 
for  changes 

Ship  hull  number(s) 

Ship  seaframe 
system(s) 

Ship(s)  availability 
requirement  (Ao) 
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Inputs 

Outputs 

Controls/Constraints 

Mechanisms 

Ship(s)  available 
space  /  dimensions 
allowance  for  parts. 

Ship(s)  available 
weight  allowance  for 
parts. 

Ship(s) 

configuration 

(APFs/AEFs) 

Ship(s)  system 

Total  ship  Ao  by 
mission  (does  not 
include  HM&E) 

Total  ship  Ao  by 
mission  (includes 
HM&E) 

User  Name  and 
Password 

Table  7.  SCMM  System  Detailed  ICOM  Table 


The  IDEFO  model  provides  a  “graphical  representation  of  the  interaction  of  the 
functional  and  physical  elements  of  a  system”  according  to  Buede  (Buede  2009,  85). 
Figure  23  shows  the  entire  detailed  ICOM  or  IDEFO,  which  is  also  shown  in  segments  in 
the  subsequent  figures  for  readability.  The  rectangular  boxes  represent  the  system 
functions;  arrows  or  arcs  represent  the  data  flows.  Inputs  enter  the  functions  boxes  from 
the  left,  are  transformed  by  that  function,  and  leave  as  outputs  from  the  right  of  the  boxes. 
Controls/constraints  enter  from  the  top  of  a  box  while  the  mechanisms  enter  from  the 
bottom  of  the  box. 
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Figure  23.  SCMM  System  IDEFO 
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Figure  24  depicts  the  SCMM  system  functions  1  and  5:  enable  graphic  user 


interface  and  maintain  system  IDEFO  with  emphasis  on  function  1 . 


User  Host  Platform 


Figure  24.  SCMM  System  Functions  1  and  5:  Enable  Graphic  User  Interface  and 

Maintain  System  IDEFO  (Function  I  Emphasis) 
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Figure  25  depicts  the  SCMM  system  functions  2,  3,  and  4:  receive  data,  process 
data,  and  provide  output  IDEFO  with  emphasis  on  function  2. 
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Figure  25.  SCMM  System  Functions  2,  3,  and  4:  Receive  Data,  Process  Data,  and 

Provide  Output  IDEFO  (Function  2  Emphasis) 
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Figure  26.  depicts  the  SCMM  system  functions  2,  3,  and  4:  receive  data,  process 
data,  and  provide  output  IDEFO  with  emphasis  on  function  3. 


Figure  26.  SCMM  System  Functions  2,  3,  and  4:  Receive  Data,  Process  Data,  and 

Provide  Output  IDEFO  (Function  3  Emphasis) 
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Figure  27  depicts  the  SCMM  system  functions  2,  3,  and  4:  receive  data,  process 
data,  and  provide  output  IDEFO  with  emphasis  on  function  4. 


Figure  27.  SCMM  System  Functions  2,  3,  and  4:  Receive  Data,  Process  Data,  and 

Provide  Output  IDEFO  (Function  4  Emphasis) 


69 


Figure  28  depicts  the  SCMM  system  functions  5  and  1:  maintain  system  and 
enable  graphic  user  interface  IDEFO  with  emphasis  on  function  5. 
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Figure  28.  SCMM  System  Functions  5  and  1:  Maintain  System  and  Enable  Graphic 

User  Interface  IDEEO  (Eunction  5  Emphasis) 
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Figure  29  depicts  the  SCMM  system  function  6:  secure  system  IDEFO. 


Figure  29.  SCMM  System  Function  6:  Secure  System  IDEFO 
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Based  on  the  detailed  ICOM  diagram,  the  team  created  a  context  diagram,  as 
shown  in  Figure  30.  The  context  diagram  helped  us  to  better  define  the  system’s 
interfaces,  as  well  as  to  better  define  the  boundaries  and  collaborating  system 
relationships  (Sage  and  Armstrong  2000).  According  to  Buede,  “The  context  of  a  system 
is  a  set  of  entities  that  can  impact  the  system  but  cannot  be  impacted  by  the  system.  The 
entities  in  the  system’s  context  are  responsible  for  some  of  the  system’s  requirements” 
(Buede  2000,  124).  Figure  30.  Figure  30  shows  the  SCMM  in  the  center  box  with  arrows 
going  in  and  out  of  the  model.  Arrows  only  feeding  into  the  model  depict  a  one-way 
relationship  in  which  the  SCMM  receives  data  from  the  external  system  interfaces, 
represented  by  the  other  white  boxes.  The  two-way  arrows  connecting  the  SCMM  system 
to  external  system  interfaces  denote  a  relationship  in  which  both  the  SCMM  system  and 
the  external  systems  exchange  information  with  each  other.  The  outside  boxes  without 
any  connecting  lines  are  actors  in  the  SCMM  system’s  environment  that  influence  the 
system  but  do  not  directly  interact  with  it. 
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Figure  30.  SCMM  System  Context  Diagram 


The  external  systems  diagram  is  created  to  make  the  boundaries  (where  the 
system  starts  and  stops)  between  the  external  systems  and  the  system  clear  (Buede  2000). 
Buede  writes  that  in  identifying  the  system’s  boundaries,  “...the  inputs  to  and  outputs  of 
the  system  are  established,  as  well  as  the  context  with  which  each  input  and  output  is 
associated”  (2000,  125). 

Buede  states  that  when  looking  at  the  system  and  modeling  the  system, 
“...everything  within  the  boundaries  of  the  system  is  open  to  change...,  and  nothing 
outside  of  the  boundaries  can  be  changed. . .”  (2000,  144),  allowing  us  to  identify  many  of 
the  system’s  constraint  requirements.  He  also  says  “The  external  systems  diagram  is  the 
model  of  the  interaction  of  the  system  with  other  (external)  systems  in  their  relevant 
contexts,  thus  providing  a  definition  of  the  system’s  boundary  in  terms  of  the  system’s 
inputs  and  outputs”  (2000,  144). 
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An  N-squared  (N^)  diagram  was  also  created  in  CORE.  The  diagram  depicts 
the  interfaces  of  the  system.  It  can  show  where  conflicts  may  be  present  and  also  serves 
to  display  assumptions  and  requirements  for  inputs  and  outputs  (National  Aeronautics 
and  Space  Administration  and  Arizona  State  University  n.d.).  According  to  a  presentation 
by  the  National  Aeronautics  and  Space  Administration  and  Arizona  State  University 
posted  on  the  Arizona  State  University  website,  the  diagram  can  also  “Demonstrate 
where  there  are  feedback  loops  between  subsystems... and...  identify  candidate 
functional  allocations  to  subsystems”  (National  Aeronautics  and  Space  Administration 
and  Arizona  State  University  n.d.).  The  N  diagram  for  the  SCMM  system  is  shown  in 
Figure  31.  The  numbered  functions  are  depicted  in  a  diagonal  line.  The  other  blocks 
represent  the  interface  inputs  and  outputs:  the  inputs  are  in  the  “columns”  and  the  outputs 
are  in  the  “rows.”  In  CORE,  blocks  with  additional  text  that  is  not  shown  is  represented 
with  a  small  black  square  in  the  upper  right-hand  side  of  the  block.  Based  on  this  diagram 
the  team  determined  that  interface  conflicts  did  not  currently  exist  in  the  system 
development. 


74 


n2  Enable  Supply  Chain  Management  Model  (SCMM)  J 
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Figure  3 1 .  SCMM  System  N-Squared  Diagram 


C.  REQUIREMENTS  ANALYSIS 

The  purpose  of  requirements  analysis  is  to  refine  customer  objectives  and 
requirements;  define  initial  performance  objectives  and  refine  them  into  requirements; 
identify  and  define  constraints  that  limit  solutions;  and  define  functional  and  performance 
requirements  based  on  customer  provided  measures  of  effectiveness.  Requirements 
analysis  should  result  in  a  clear  understanding  of: 

•  Operational  requirements 

•  Input  and  output  performance  requirements 
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•  Functional  requirements 

•  Interface  constraints 

•  Suitability  requirements 

•  Other  requirements  and  constraints. 

1.  Originating  Requirements 

System  requirements  definition  and  management  began  with  originating 
requirements.  According  to  Buede,  these  are  derived  from  operational  needs:  “...top- 
level  statements  defined  in  language  that  is  understandable  to  the  stakeholders,  leaving 
room  for  design  flexibility”  (2000,  128).  They  “...define  the  essence  of  the  stakeholders’ 
needs  clearly  for  the  stakeholders  to  be  completely  satisfied  with  whatever  system  results 
from  the  systems  engineering  process”  (Buede  2000,  128).  Design  independence  is  a 
major  emphasis  when  developing  the  originating  requirements:  the  originating 
requirements  should  not  overly  constrain  the  solution  space  because  this  would  impede 
the  design  process  (Buede  2000).  Buede  states  that  defining  the  originating  requirements 
takes  into  account  the  “...need  to  have  and  define  a  large  tradable  region  in  [the]  design 
space  for  the  system  engineers  to  search  with  quantitative  techniques  utilizing  the 
priorities  of  the  stakeholders”  (2000,  123). 

Once  the  originating  requirements  were  defined,  the  team  developed  the  derived 
requirements,  the  requirements  defined  by  the  team  in  engineering  terms  during  the 
design  process.  Derived  requirements  were  needed  to  complete  the  design  to  sufficient 
detail  for  the  specification  to  be  delivered  to  the  design  teams  responsible  for  the 
configuration  items  of  the  system.  According  to  Buede,  “...the  goal  of  the  design  process 
is  to  create  a  system  specification  that  can  be  developed  into  specifications  for  the 
system’s  components,  which  are  then  segmented  into  specifications  for  the  system 
configuration  items  (CIs)”  (Buede  2000,  121).  A  result  of  this  design  process  was  the 
creation  of  two  hierarchies  of  requirements,  as  shown  in  Figure  32. 
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Figure  32.  Hierarchies  of  Requirements  (after  Buede  2000,  122) 

Although  the  team  was  unable  to  derive  the  full  set  of  requirements  for  the  SCMM 
system,  the  ones  that  were  identified  were  captured  and  modeled  in  CORE,  and  are 
shown  and  discussed  in  the  subsequent  pages. 

The  originating  requirement  for  the  SCMM  system  is  the  need  statement, 
previously  identified  as:  The  stakeholders  need  information  to  determine  sparing  of  parts 
at  existing  and  multiple  supply  points  in  order  to  support  the  Navy’s  modular/flexible 
ships  within  the  constraints  of  manning,  space,  weight,  location,  and  cost/budget.  The 
capabilities  identified  by  the  sponsor  were  also  taken  into  account  during  the  derivation 
of  the  requirements.  Those  capabilities  are  convert  (or  process)  data  inputs  into 
information  to  be  used  for  sparing  of  parts  at  various  locations  based  on  the  use  case 
scenarios  and  allow  the  users  to  conduct  sensitivity  analysis  based  on  the  inputs  for 
trade-off  analysis  for  cost,  operational  availability  (Ao),  personnel  requirements,  weight, 
and/or  space,  both  derived  from  the  need  statement. 

2.  Requirements  Analysis  Framework 

The  team  based  the  requirements  analysis  on  Buede ’s  methodology,  creating  a 
framework  for  the  SCMM  system’s  requirements.  Figure  33  Figure  33.  shows  the  top- 
level  system  requirements  diagram.  Requirements  1-4  are  further  decomposed  and 
explained  in  the  following  sections.  A  table  listing  the  requirements  was  also  developed, 
and  will  be  discussed  following  the  requirements  framework  figures. 
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Figure  33.  Top-Level  Requirements 


3.  Input/Output  Requirements 

According  to  Buede,  “Input/output  requirements  include  sets  of  acceptable  inputs 
and  outputs,  trajectories  of  inputs  to  and  outputs  from  the  system,  interface  constraints 
imposed  by  the  external  systems,  and  eligibility  functions  that  match  system  inputs  with 
system  outputs...”  (2000,  130). 

Buede  states  that  there  are  four  subsets  in  this  category:  “(a)  system  input 
performance  (b)  system  output  performance,  (c)  system  interoperability/external  interface 
constraints,  and  (d)  system  functionality/functional  requirements”  (2000,  132),  as  shown 
in  Figure  34. 
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Figure  34.  System  Inputs/Outputs  Hierarchy 


78 


a.  System  Input  Performance 

System  input  performance  requirements  state  what  inputs  the  system  must  receive 
and  the  performance  or  constraint  attributes  of  each  (Buede  2000). 

b.  System  Output  Performance 

System  output  performance  requirements  state  what  outputs  the  system  must 
produce  and  the  performance  attributes  of  each  (Buede  2000). 

c.  System  Interoperability/External  Interface  Constraints 

According  to  Buede,  system  interoperability  /  external  interface  constraint 

“...requirements  are  usually  constraints  that  define  the  reception  of  inputs  and 
transmission  of  outputs  between  the  system  and  the  system’s  environment  (2000,  130). 
The  interface  requirements  consist  of  the  constraints,  processes,  and  specifications 
required  for  the  system  to  interface  with  other  systems  outside  the  boundaries  set  for  the 
SCMM  system.  These  interfaces  can  be  divided  as  hardware-to-hardware,  software-to- 
software,  or  hardware-to-software.  Interface  requirements  are  necessary  to  ensure  that  the 
SCMM  system  is  able  to  share  data,  communicate,  and  function  with  the  required 
external  systems. 

d.  System  Functionality/Functional  Requirements 

Buede  writes  that 

...functional  requirements  relate  to  specific  functions  (at  any  level  of  abstraction) 
that  the  system  must  perform  while  transforming  inputs  into  outputs.  As  a  result,  a 
functional  requirement  is  a  requirement  that  can  be  associated  with  one  or  more  of  the 
system’s  outputs  (2000,  130). 

4.  Technology  and  Suitability  Requirements 

The  technology  and  suitability  requirements,  according  to  Buede, 

...consist  of  constraints  and  performance  index  thresholds  (e.g.,  the  length 

of  the  operational  life  for  the  system,  the  cost  of  the  system  in  various  life- 

cycle  phases,  and  the  system’s  availability)  that  are  placed  upon  the 
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physical  resources  of  the  system.  Many  of  the  requirements  from  each 
phase  of  the  system’s  life  cycle  are  found  in  this  category  because  these 
requirements  specifically  relate  to  the  physical  manifestation  of  the 
system.  This  category  can  be  partitioned  into  four  subsets:  (a)  [system] 
technology  (b)  [system]  suitability  and  quality  issues,  (c)  cost  for  the 
relevant  system  (e.g.,  development  cost,  operational  cost),  and  (d) 
[system]  schedule  for  the  relevant  life  cycle  phase  (e.g.,  development  time 
period,  operational  life  of  the  system).  (  2000,  132) 

Figure  35  depicts  the  system  technology  and  suitability  requirements  hierarchy. 
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Figure  35.  System  Technology  and  Suitability  Requirements  Hierarchy 


a.  System  Technology 

System  technology  requirements  constrain  the  system  design;  therefore,  it  is 
preferable  to  have  as  few  as  possible.  They  should  be  included  to  ensure  compatibility  or 
interoperability  with  existing  systems  and/or  products,  which  should  result  in  cost  savings 
(Buede  2000). 

b.  System  Suitability 

System  suitability  requirements  are  system-wide  in  scope.  They  include  the 
ilities,”  which  have  parameters  assigned  to  ensure  the  security,  usability,  availability, 
reliability,  maintainability,  durability,  and  supportability  of  the  system  (Buede  2000). 
Figure  36  shows  the  next  level  of  the  SCMM  system’s  suitability  requirements  hierarchy. 
It  includes  system  availability,  extensibility  (growth  potential),  maintainability,  security, 
testability,  usability,  duration,  form  and  fit,  reliability,  supportability,  and  trainability. 
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Requirements  were  derived  for  some  of  these  areas  but  further  decomposition  is  required 
to  ensure  the  system  meets  the  needs  of  the  stakeholders. 


Figure  36.  System  Suitability  Requirements  Hierarchy 


c.  System  Cost 

System  cost  consists  of  the  SCMM  development  cost,  the  production  cost,  the 
deployment  cost,  and  the  decommission  cost  (Buede  2000).  Overall,  the  system  cost  is 
the  affordability  for  operating  and  maintenance  (Buede  2000).  Cost  requirements  were 
not  identified  for  the  SCMM  system  due  to  the  time  constraints  of  the  capstone  project’s 
timeframe.  Figure  37  depicts  the  next  level  of  the  system  cost  requirements  hierarchy. 


2.3 

System  Cost 

Requirement 

refined  by 

refined  by 

refined  by 

refined  by 

2.3.1 

2.3.2 

2.3.3 

2.3.4 

Development  Cost 

Production  Cost 

Deployment  Cost 

Decomission  Cost 

Requirement 

Requirement 

Requirement 

Requirement 

Figure  37.  System  Cost  Requirements  Hierarchy 
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d.  System  Schedule 

System  schedule  contains  the  required  time  frame  for  development,  manufacture 
of  each  unit,  training  time  to  reach  proficiency  by  category  of  the  users,  deployment,  and 
durability  or  operational  life  of  the  system  (Buede  2000).  Cost  requirements  were  not 
identified  for  the  SCMM  system  due  to  the  time  constraints  of  the  capstone  project’s 
timeframe.  Figure  38  displays  the  next  level  of  the  system  schedule  requirements 
hierarchy. 


Figure  38.  System  Schedule  Requirements  Hierarchy 


5.  System  Trade-Off  Requirements 

As  stated  by  Buede,  the  system  trade-off  requirements: 

...are  algorithms  for  comparing  any  two  alternate  designs  on  the 
aggregation  of  cost  and  performance  objectives.  These  algorithms  can  be 
divided  into  (a)  [system]  performance  trade-offs,  (b)  [system]  cost  trade¬ 
offs,  and  (c)  [system]  cost-performance  trade-offs.  The  performance  trade¬ 
off  algorithm  defines  how  the  relative  performance  of  any  two  alternate 
designs  can  be  compared  in  terms  of  the  system’s  performance  objectives. 
These  performance  objectives  are  defined  within  the  input/output  and  non¬ 
cost  system- wide  requirements.  (Buede  2000,  132-133) 

Figure  39  depicts  the  system  trade-offs  requirements  hierarchy. 
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Figure  39.  System  Trade-Offs  Requirement  Hierarchy 


a.  System  Performance  Trade-offs 

Buede  writes  that  the  system  performance  trade-off  is  performed  with  an 
algorithm  that  “...defines  how  the  performance  parameters  are  to  be  compared  to  each 
other”  (Buede  2000,  133). 

b.  System  Cost  Trade-offs 

The  system  cost  trade-off  is  performed  with  an  algorithm  that  “...defines  how  the 
relative  cost  of  any  two  alternate  designs  can  be  compared  across  all  cost  parameters 
(life-cycle  phases)  of  interest  to  the  stakeholders,”  according  to  Buede  (2000,  133). 

c.  System  Cost-Performance  Trade-offs 

Buede  continues  that  the  system  cost-performance  trade-off  is  performed  with  an 
algorithm  that  defines  “...how  performance  objectives  should  be  traded  with  cost 
objectives”  (Buede  2000,  133). 

The  team  was  unable  to  address  the  system  trade-off  requirements  within  the 
timeframe  allotted  for  this  project. 

6.  System  Qualification  Requirements 

According  to  Buede,  the  system  qualification  requirements  “...address  the  needs 

to  qualify  the  system  as  being  designed  right,  the  right  system,  and  an  acceptable  system” 
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(Buede  2000,  133).  This  area  is  composed  of  four  primary  elements:  system  observance, 
system  verification,  system  validation,  and  system  acceptance,  as  shown  in  Figure  40. 


Figure  40.  System  Qualification  Requirement  Hierarchy 


a.  System  Observance 

Buede  writes  that  system  observance  is  used  “...to  state  which  qualification  data 
for  each  input/output  and  system-wide  requirement  will  be  obtained  by  (i)  demonstration, 
(ii)  analysis  and  simulation,  (iii)  inspection,  or  (iv)  instrumented  test”  (2000,  133). 

b.  System  Verification 

A  system  verification  plan  is  developed  “. .  .to  state  how  the  qualification  data  will 
be  used  to  determine  that  the  real  system  conforms  to  the  design  that  was  developed,” 
according  to  Buede  (2000,  133). 

c.  System  Validation 

Buede  articulates  that  a  system  validation  plan  is  developed  “...to  state  how  the 
qualification  data  will  be  used  to  determine  that  the  real  system  complies  with  the 
originating  performance,  cost,  and  trade-off  requirements”  (2000,  134). 

d.  System  Acceptance 

A  system  acceptance  plan  is  developed,  as  Buede  says,  “...to  state  how  the 
qualification  data  will  be  used  to  determine  that  the  real  system  is  acceptable  to  the 
stakeholders”  (2000,  134). 
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Although  the  team  was  unable  to  address  the  qualification  requirements  in  CORE 
within  the  timeframe  allotted  for  this  project,  a  test  plan  was  developed  and  testing  was 
performed  on  a  simulation  of  the  SCMM  system  that  was  developed  during  the  modeling 
and  simulation  phase.  Information  on  testing  can  be  found  in  the  Integration  and  Test 
section  of  Chapter  VII. 

7.  Derived  Requirements 

The  originating  requirement  was  decomposed  to  obtain  the  system  requirements. 
Table  8  was  developed  from  the  SCMM  system’s  requirements  information  entered  into 
CORE.  The  numbering  shows  the  indentured  structure  of  the  requirements,  which 
correspond  to  the  requirements  framework  discussed  in  the  previous  paragraphs. 
Requirements  derivation  was  not  completed  to  the  fullest  extent  possible,  but  did  allow 
for  a  conceptual  design  to  be  developed,  simulated,  and  tested.  An  analysis  of  alternatives 
and  cost  analysis  were  also  conducted  based  on  a  number  of  the  requirements. 


Requirements 

Number 

Name 

1 

System  Inputs/Outputs 

1.1 

System  Input  Performance 

1.1.1 

The  system  shall  receive  Assigned  RMC  information  with  100% 
accuracy. 

1.1.2 

The  system  shall  receive  Budget  information  with  100%  accuracy. 

1.1.3 

The  system  shall  receive  DEA  Distribution  Centers  information  with 
100%  accuracy. 

1.1.4 

The  system  shall  receive  Duration  of  operation(s)  information  with 
100%  accuracy. 

1.1.5 

The  system  shall  receive  Elect  area/location  of  operation  information 
with  100%  accuracy. 

1.1.6 

The  system  shall  receive  Elect  Eogistics  Centers  (formerly  EISCs: 
Elect  and  Industrial  Support  Centers)  information  with  100% 
accuracy. 

1.1.7 

The  system  shall  receive  Maintenance  facility  locations(s)  information 
with  100%  accuracy. 

1.1.8 

The  system  shall  receive  Mission  module(s)  information  with  100% 
accuracy. 
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Requirements 

Number 

Name 

1.1.9 

The  system  shall  receive  Mission  module(s)  Ao  information  with 
100%  accuracy. 

1.1.10 

The  system  shall  receive  Mission  module(s)  configuration 
(APLs/AELs)  information  with  100%  accuracy. 

1.1.11 

The  system  shall  receive  Mission  module(s)  container  available  space 
/  dimensions  allowance  for  parts  information  with  100%  accuracy. 

1.1.12 

The  system  shall  receive  Mission  module(s)  container  available 
weight  allowance  for  parts  information  with  100%  accuracy. 

1.1.13 

The  system  shall  receive  Mission  package  (e.g.,  SUW,  ASW,  MCM, 
humanitarian)  information  with  100%  accuracy. 

1.1.14 

The  system  shall  receive  Part  cage  code(s)  information  with  100% 
accuracy. 

1.1.15 

The  system  shall  receive  Part  cost(s)  information  with  100%  accuracy. 

1.1.16 

The  system  shall  receive  Part  criticality  information  with  100% 
accuracy. 

1.1.17 

The  system  shall  receive  Part  dimensions  information  with  100% 
accuracy. 

1.1.18 

The  system  shall  receive  Part  estimated  shipping  time  information 
with  100%  accuracy. 

1.1.19 

The  system  shall  receive  Part  failure  rate/MTBF  information  with 
100%  accuracy. 

1.1.20 

The  system  shall  receive  Part  HA /.MAT  information  with  100% 
accuracy. 

1.1.21 

The  system  shall  receive  Part  item  manager  POC  information  with 
100%  accuracy. 

1.1.22 

The  system  shall  receive  Part  maintenance  code(s)  information  with 
100%  accuracy. 

1.1.23 

The  system  shall  receive  Part  nomenclature(s)  information  with  100% 
accuracy. 

1.1.24 

The  system  shall  receive  Part  NSN(s)  information  with  100% 
accuracy. 

1.1.25 

The  system  shall  receive  Part  number(s)  information  with  100% 
accuracy. 

1.1.26 

The  system  shall  receive  Part  weight  information  with  100%  accuracy. 

1.1.27 

The  system  shall  receive  Planned  changes  to  mission  module’s 
configuration/dates  for  changes  information  with  100%  accuracy. 

1.1.28 

The  system  shall  receive  Planned  changes  to  ship’s 
configuration/dates  for  changes  information  with  100%  accuracy. 

1.1.29 

The  system  shall  receive  Ship  hull  number(s)  information  with  100% 
accuracy. 
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Requirements 

Number 

Name 

1.1.30 

The  system  shall  reeeive  Ship  seaframe  system(s)  information  with 
100%  accuracy. 

1.1.31 

The  system  shall  receive  Ship(s)  availability  requirement  (Ao) 
information  with  100%  accuracy. 

1.1.32 

The  system  shall  receive  Ship(s)  available  space  /  dimensions 
allowance  for  parts  information  with  100%  accuracy. 

1.1.33 

The  system  shall  receive  Ship(s)  available  weight  allowance  for  parts 
information  with  100%  accuracy. 

1.1.34 

The  system  shall  receive  Ship(s)  configuration  (APLs/AELs) 
information  with  100%  accuracy. 

1.1.35 

The  system  shall  receive  Ship(s)  system  information  with  100% 
accuracy. 

1.1.36 

The  system  shall  receive  Total  ship  Ao  by  mission  (includes  HM&E) 
information  with  100%  accuracy. 

1.1.37 

The  system  shall  receive  Total  ship  Ao  by  mission  (does  not  include 
HM&E)  information  with  100%  accuracy. 

1.1.38 

The  system  shall  receive  Password  with  100%  accuracy. 

1.1.39 

The  system  shall  receive  Username  with  100%  accuracy. 

1.2 

System  Output  Performance 

1.2.1 

The  system  shall  output  Total  weight  of  mission  module(s) 
container(s)  spares  with  an  accuracy  of  100%. 

1.2.2 

The  system  shall  output  Total  space  of  shipboard  spares  with  an 
accuracy  of  100%. 

1.2.3 

The  system  shall  output  Total  space  of  mission  module(s)  container(s) 
spares  with  an  accuracy  of  100%. 

1.2.4 

The  system  shall  output  Total  cost  of  parts  allocated  with  an  accuracy 
of  100%. 

1.2.5 

The  system  shall  output  Summary  of  inputs  with  an  accuracy  of  100%. 

1.2.6 

The  system  shall  output  Spares  allocation  on  ship  with  an  accuracy  of 
no  less  than  99%. 

1.2.7 

The  system  shall  output  Spares  allocation  for  mission  module(s) 
container(s)  with  an  accuracy  of  no  less  than  99%. 

1.2.8 

The  system  shall  output  Spares  allocation  at  OCONUS  warehouse 
locations  with  an  accuracy  of  no  less  than  99%. 

1.2.9 

The  system  shall  output  Spares  allocation  at  land-based  maintenance 
facilities  with  an  accuracy  of  no  less  than  99%. 

1.2.10 

The  system  shall  output  Projected  Ao  of  ship(s)  with  an  accuracy  of 
no  less  than  99%. 

1.2.11 

The  system  shall  output  Graphical  Output  with  an  accuracy  of  100%. 
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Requirements 

Number 

Name 

1.2.12 

The  system  shall  output  Sensitivity  Analysis  -  Weight  with  an 
accuracy  of  100%. 

1.2.13 

The  system  shall  output  Sensitivity  Analysis  -  Space  with  an  accuracy 
of  100%. 

1.2.14 

The  system  shall  output  Sensitivity  Analysis  -  Budget  with  an 
accuracy  of  100%. 

1.2.15 

The  system  shall  output  Sensitivity  Analysis  -  Ao  with  an  accuracy  of 
100%. 

1.2.16 

The  system  shall  produce  a  graphical  output  within  a  maximum  time 
of  5  seconds. 

1.3 

System  Interoperability/External  Interface  Constraints 

1.3.1 

The  system  shall  interface  with  NDE:  AMPS 

1.3. 1.1 

The  system  shall  accept  a  data  push  from  NDE:  AMPS  every  24  hours 
at  midnight  (PST). 

1.3.2 

The  system  shall  interface  with  NDE:  CDMD-OA 

1.3.2.1 

The  system  shall  accept  a  data  push  from  NDE:  CDMD-OA  every  24 
hours  at  midnight  (PST). 

1.3.3 

The  system  shall  interface  with  NAVSUP  ERP. 

1.3.3. 1 

The  system  shall  accept  a  data  push  from  NAVSUP  ERP  every  24 
hours  at  midnight  (PST). 

1.3.4 

The  system  shall  interface  with  user  host  platform(s). 

1.3.5 

The  system  shall  be  interoperable  with  the  DOD  GIG. 

1.4 

System  Eunctionality/Eunctional  Requirements 

1.4.1 

The  system  shall  enable  a  graphical  user  interface  (GUI). 

1.4.1. 1 

The  system  shall  display  a  login  screen  in  no  more  than  1  minute. 

1.4.1. 1.1 

The  system  shall  accept  a  user  name  and  password  in  no  more  than  5 
seconds. 

1.4.1.2 

The  system  shall  perform  a  login  credential  security  verification  in  no 
more  than  2  seconds. 

1.4.1.2.1 

The  system  shall  invalidate  a  login  due  to  an  incorrect  password  entry 
in  no  more  than  1  second. 

1.4.1.2.2 

The  system  shall  invalidate  a  login  due  to  an  incorrect  username  entry 
in  no  more  than  1  second. 

1.4.1.2.3 

The  system  shall  validate  a  login  due  to  a  correct  username  and 
password  entry  in  no  more  than  1  second. 

1.4.1.3 

The  system  shall  display  a  graphic  user  interface  in  no  more  than  5 
seconds. 

1.4.1.4 

The  system  shall  enable  data  entry/selection  fields  in  no  more  than  5 
seconds. 
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Requirements 

Number 

Name 

1.4.2 

The  system  shall  reeeive  data. 

1.4.2.1 

The  system  shall  accept  a  user’s  input/selection  in  no  more  than  2 
seconds. 

1.4.2.1.1 

The  system  shall  verify  the  user’s  inputs/selected  data  in  no  more  than 

2  seconds. 

1.4.2.1.1.1 

The  system  shall  invalidate  incorrect  user  inputs  in  no  more  than  2 
seconds 

1.4.2.1.1.2 

The  system  shall  validate  correct  user  inputs  in  no  more  than  2 
seconds. 

1.4.2.2 

The  system  shall  accept  data  from  external  databases  in  no  more  than 

1  hour. 

1.4.2.2.1 

The  system  shall  verify  data  integrity  (complete/correct/does  not 
contain  errors)  in  no  more  than  30  minutes. 

1.4.2.2.1.1 

The  system  shall  invalidate  incorrect  database  data  in  no  more  than  30 
minutes. 

1.4.2.2.1.2 

The  system  shall  validate  correct  external  database  data  in  no  more 
than  30  minutes. 

1.4.2.2.2 

The  system  shall  integrate  the  data  into  a  repository  in  no  more  than 
15  minutes. 

1.4.2.2.3 

The  system  shall  save  data  in  a  system  repository  in  no  more  than  15 
minutes. 

1.4.3 

The  system  shall  process  data. 

1.4.3.1 

The  system  shall  process  requests  in  no  more  than  1  second. 

1.4.3.2 

The  system  shall  execute  queries  in  no  more  than  1  second. 

1.4.3.3 

The  system  shall  verify  query  requirements  are  being  met  in  no  more 
than  1  second. 

1.4.3.3.1 

The  system  shall  invalidate  incomplete/incorrect  queries  in  no  more 
than  1  second. 

1.4.3.3.2 

The  system  shall  validate  complete/correct  queries  in  no  more  than  1 
second. 

1.4.3.4 

The  system  shall  obtain  filtered  data  from  the  repository  in  no  more 
than  2  minutes. 

1.4.3.5 

The  system  shall  perform  sparing  analysis  in  no  more  than  5  minutes. 

1.4.4 

The  system  shall  provide  outputs. 

1.4.4.1 

The  system  shall  display  sparing  results  (graphical  output  based  on 
user’s  query)  in  no  more  than  1  second. 

1.4.4.1.1 

The  system  shall  allow  the  user  to  save  sparing  results  in  no  more  than 

1  second. 
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Requirements 

Number 

Name 

1.4.4.1.2 

The  system  shall  allow  the  user  to  print  sparing  results  in  no  more  than 

1  second. 

1.4.4.1.3 

The  system  shall  allow  the  user  to  perform  sensitivity  analysis  in  no 
more  than  1  second. 

1.4.4.1.4 

The  system  shall  allow  the  user  to  delete  results  in  no  more  than  1 
second. 

1.4.5 

The  system  shall  provide  self-maintenance  through  a  series  of  checks 
and  display  the  information  to  the  user. 

1.4.5. 1 

The  system  shall  execute  self-checks  in  no  more  than  2  seconds. 

1.4.5.1.1 

The  system  shall  execute  a  repository  check  in  no  more  than  0.5 
seconds. 

1.4.5. 1.2 

The  system  shall  execute  an  interface  check  in  no  more  than  1  second. 

1.4.5. 1.2.1 

The  system  shall  execute  an  interface  check  of  the  system  side  in  no 
more  than  0.5  seconds. 

1.4.5. 1.2.2 

The  system  shall  execute  an  interface  check  of  the  external  databases 
in  no  more  than  0.5  seconds. 

1.4.5. 1.2.2.1 

The  system  shall  display  a  status  of  the  external  databases  in  no  more 
than  0.5  seconds. 

1.4.5. 1.3 

The  system  shall  execute  a  processes  check  in  no  more  than  0.5 
seconds. 

1.4.5.2 

The  system  shall  provide  the  user  with  a  maintenance  history  in  no 
more  than  1  second. 

1.4.5.2.1 

The  system  shall  display  the  time  and  date  of  the  last  database  data 
download  in  no  more  than  1  second. 

1.4.5.2.2 

The  system  shall  display  the  time  and  date  of  the  last  login  in  no  more 
than  1  second. 

1.4.6 

The  system  shall  secure  itself. 

1.4.6.1 

The  system  shall  comply  with  DOD  and  DoN  Information  Assurance 
(lA)  policies  and  procedures. 

1.4.6.2 

The  system  shall  secure  the  GUI  continuously. 

1.4.6.3 

The  system  shall  secure  the  log-in  process  when  in  login  screen. 

1.4.6.4 

The  system  shall  secure  the  repository  continuously. 

1.4.6.5 

The  system  shall  secure  the  interfaces  with  the  external  databases 
continuously. 

2 

System  Technology  and  Suitability 

2.1 

System  Technology 

2.1.1 

The  system  shall  be  hosted  on  a  DOD  authorized  platform. 

2.1. 1.1 

The  platform  shall  have  a  GIG  compatible  connection  device. 
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Requirements 

Number 

Name 

2.1. 1.2 

The  platform  shall  have  a  storage  device  (i.e.,  harddrive,  server, 
cloudserver) 

2.1. 1.3 

The  platform  shall  have  a  viewing  device  (i.e.,  monitor,  viewscreen) 

2.1. 1.4 

The  platform  shall  have  an  input  device(s)  (i.e.,  keyboard,  mouse, 
touchscreen). 

2.1. 1.5 

The  platform  shall  have  an  output  device  (i.e.,  printer) 

2.1.2 

The  system  shall  conform  to  a  modular  open  systems  approach 
(MOSA). 

2.1.2.1 

The  system  shall  conform  to  MOSA  by  adapting  to  evolving 
requirements. 

2.1.2.2 

The  system  shall  conform  to  MOSA  by  enhancing  access  to  cutting 
edge  technologies  and  products. 

2.1.2.3 

The  system  shall  conform  to  MOSA  by  enhancing  commonality  and 
reuse  of  components  among  systems. 

2.1.2.4 

The  system  shall  conform  to  MOSA  by  enhancing  life-cycle 
supportability. 

2.1.2.5 

The  system  shall  conform  to  MOSA  by  ensuring  that  the  system  will 
be  fully  interoperable  with  all  the  systems  with  which  it  must  interface 
without  major  modification  of  existing  components. 

2.1.2.6 

The  system  shall  conform  to  MOSA  by  facilitating  systems 
integration. 

2.1.2.7 

The  system  shall  conform  to  MOSA  by  mitigating  the  risk  associated 
with  technology  obsolescence. 

2.1.2.8 

The  system  shall  conform  to  MOSA  by  mitigating  the  risk  of  a  single 
source  of  supply  over  the  life  of  the  system. 

2.1.2.9 

The  system  shall  conform  to  MOSA  by  reducing  the  development 
cycle  time. 

2.1.2.10 

The  system  shall  conform  to  MOSA  by  reducing  total  lifecycle  cost. 

2.2 

System  Suitability  and  Quality  Issues 

2.2.1 

System  Availability 

2.2.1. 1 

The  system  shall  be  available  at  all  times  other  than  during  a  data 
push. 

2.2.2 

System  Duration 

2.2.3 

System  Extensibility  (Growth  Potential) 

2.2.3. 1 

The  system  shall  be  modifiable. 

2.2.4 

System  Form  and  Fit 

2.2.4. 1 

The  system  shall  be  contained  on  a  portable  device  (i.e.,  CD,  USB 
stick,  DVD) 

2.2.5 

System  Maintainability 

2.2.6 

System  Reliability 
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Requirements 

Number 

Name 

2.2.6.1 

The  system  shall  have  a  failure  rate  of  no  less  than  0.000002. 

2.2.7 

System  Security 

2.2.8 

System  Supportability 

2.2.8. 1 

The  system  shall  be  supportable  over  the  DOD  GIG. 

2.2.9 

System  Testability 

2.2.10 

System  Trainability 

2.2.10.1 

The  system  shall  have  a  built-in  help  menu/function. 

2.2.10.2 

The  system  shall  have  a  built-in  user’s  guide. 

2.2.10.3 

The  system  shall  have  an  accompanying  user’s  manual. 

2.2.11 

System  Usability 

2.2.11.1 

The  system  shall  comply  with  DOD  human  system  integration 
standards/specifications. 

2.3 

System  Cost 

2.3.1 

Development  Cost 

2.3.2 

Production  Cost 

2.3.3 

Deployment  Cost 

2.3.4 

Decommission  Cost 

2.4 

System  Schedule 

2.4.1 

Development  Schedule 

2.4.2 

Manufacturing  Schedule 

2.4.3 

User/Role  Specific  Training  Time  and  Schedule 

2.4.4 

Deployment  Schedule 

2.4.5 

Operational  Life  of  the  System  Schedule 

3 

System  Trade-Offs 

3.1 

System  Performance  Trade-Offs 

3.2 

System  Cost  Trade-Offs 

3.3 

System  Cost-Performance  Trade-Offs 

4 

System  Qualification 

4.1 

System  Observance 

4.2 

System  Verification 

4.3 

System  Validation 

4.4 

System  Acceptance 

Table  8.  SCMM  System  Requirements 


92 


D.  SUMMARY 


After  the  identifying  the  system  capability  gaps  during  the  needs  analysis  phase  of 
the  tailored  SE  process,  the  team  began  the  process  of  identifying  system  requirements 
and  proceeding  with  a  detailed  requirements  analysis  to  establish  parameters  during  the 
design  of  the  system.  Investigation  of  current  system  structures  and  interoperability  was 
documented  to  allow  for  development  of  a  system  to  satisfy  the  stakeholders’  needs.  A 
model  based  systems  engineering  approach  was  used  to  create  the  architecture,  functions, 
requirements,  and  DODAF  views  in  Vitech’s  CORE  to  maintain  traceability  and 
refinement  throughout  the  process.  CORE’S  inherent  traceability  allowed  for  efficient 
refinement  for  detailed  requirement  iterations  from  an  established  baseline  during 
discussions  with  the  sponsor.  The  constructed  models  were  significant  in  visualizing  and 
communicating  system  functions  to  the  sponsor  for  verification  of  the  system 
architecture. 

Boundary  definition  of  the  system  was  completed  to  separate  and  connect  the 
SCMM  system  to  inputs  and  outputs  that  were  determined  to  be  a  part  of  the  system 
environment.  The  creation  of  diagrams  and  models  were  completed  to  fully  scope  and 
bound  the  identified  problem.  The  RSRP  team  created  an  ICOM  diagram  to  identify;  the 
inputs  that  would  be  entering  the  system,  the  outputs  that  the  system  would  be  producing, 
the  controls  that  would  direct  the  process  activities,  and  the  resources  and  tools  that 
would  act  as  mechanisms  to  realize  the  functions.  A  context  diagram  was  created  based 
on  the  detailed  ICOM  diagram  to  show  the  system  interfaces  and  relationships  with 
external  systems.  To  help  identify  any  interface  conflicts  an  N2  diagram  was  developed, 
thus  ensuring  the  development  of  the  system  could  proceed. 

Project  Team  RSRP  defined  the  originating  requirements  by  analyzing  the 
individual  stakeholder  needs  and  determining  the  critical  requirements  for  the  overall 
system  through  discussions  with  the  sponsor.  Once  these  critical  requirements  were 
determined  the  team  was  able  to  develop  derived  requirements  including  system 
requirements  and  component  requirements  that  were  further  analyzed  during  the  system 
design  phase  for  system  alternatives.  The  system  requirements  were  decomposed  into  the 

following  categories:  System  Inputs/Outputs  requirements.  System  Technology  and 
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Suitability  requirements,  System  Trade-Off  requirements,  and  System  Qualification 
requirements.  Subsequent  requirements  for  each  top  level  category  were  created  by  the 
team  in  CORE  and  were  to  be  used  during  the  conceptual  design  phase  for  development 
of  the  system  components. 
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IV.  SYSTEM  ARCHITECTURE 


The  system  architecture  phase  captured  the  logical  sequencing  and  interaction  of 
system  functions  or  logical  elements.  The  system  architecture  was  documented  using 
CORE,  which  also  provided  a  MBSE  capability.  The  team  utilized  DODAE  v2.02  to 
define  the  different  architecture  views  of  the  design.  The  DODAE  was  used  to  ensure  that 
architecture  descriptions  were  compared  and  related  across  organizational  boundaries;  it 
defined  a  common  approach  for  DOD  architecture  description,  development, 
presentation,  and  integration  (Vickers  and  Charles -Vickers  2006).  Three  architectural 
views,  capability  view  (CV),  operational  views  (OVs),  and  system  views  (SVs),  were 
created  to  show  the  overall  system  capability  along  with  the  relationship  of  inputs  and 
outputs  and  constraints  and  mechanisms  of  the  system  design.  The  output  of  this  phase 
was  a  high  level  system  design  and  a  generic  architecture  that  met  the  needs  of  the 
stakeholders. 

A.  DODAF  ROADMAP 

According  to  the  Deputy  Chief  Information  Officer,  the  Department  of  Defense 
Architecture  Eramework  (DODAE)  is  a  document  that  provides  an: 

...overarching,  comprehensive  framework  and  conceptual  model  enabling 
the  development  of  architectures  to  facilitate  the  ability  of  Department  of 
Defense  (DOD)  managers  at  all  levels  to  make  key  decisions  more 
effectively  through  organized  information  sharing  across  the  Department, 

Joint  Capability  Areas  (JCAs),  Mission,  Component,  and  Program 
boundaries.  The  DODAE  serves  as  one  of  the  principal  pillars  supporting 
the  DOD  Chief  Information  Officer  (CIO)  in  his  responsibilities  for 
development  and  maintenance  of  architectures  required  under  the  Clinger- 
Cohen  Act.  DODAE  is  prescribed  for  the  use  and  development  of 
Architectural  Descriptions  in  the  Department.  It  also  provides  extensive 
guidance  on  the  development  of  architectures  supporting  the  adoption  and 
execution  of  Net-centric  services  within  the  Department.  (Deputy  Chief 
Information  Officer  2010,  3) 

Every  view  of  the  DODAE  2.02  cannot  be  used  due  to  redundancy  or 
inapplicability.  In  the  DODAE  it  is  suggested  to  use  a  “fit-for-purpose”  methodology. 


The  Deputy  Chief  Information  Officer  states: 
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The  DODAF  enables  architectural  content  that  is  “Fit-for-Purpose”  as  an 
architectural  description  consistent  with  specific  project  or  mission 
objectives.  Because  the  techniques  of  architectural  description  can  be 
applied  at  myriad  levels  of  an  enterprise,  the  purpose  or  use  of  an 
architectural  description  at  each  level  will  be  different  in  content, 
structure,  and  level  of  detail.  Tailoring  the  architectural  description 
development  to  address  specific,  well-articulated,  and  understood 
purposes,  will  help  ensure  the  necessary  data  is  collected  at  the  appropriate 
level  of  detail  to  support  specific  decisions  or  objectives.  (Deputy  Chief 
Information  Officer  2010,  3) 

This  allowed  the  team  to  select  various  views  to  create  the  DODAF  “roadmap” 
for  the  SCMM  system.  The  selection  of  views  that  Team  RSRP  chose  to  define  and 
communicate  the  system  design  to  the  sponsor  and  stakeholders  included  a  CV-1,  OV-1, 
OV-2,  OV-5,  SV-1,  SV-4,  and  SV-5.  Figure  41  displays  the  links  between  these  views. 
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high  level 
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Figure  41.  SCMM  System  DODAF  Roadmap 
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B.  DODAF  VIEWS 


The  views  are  explained  and  depicted  in  the  ensuing  paragraphs. 

1.  CV-1 

The  CV-1  is  a  capability  viewpoint  diagram  that  was  created  in  PowerPoint.  The 
Deputy  Chief  Information  Officer  defines  the  CV-1  as: 

The  CV-1  addresses  the  enterprise  concerns  associated  with  the  overall 
vision  for  transformational  endeavors  and  thus  defines  the  strategic 
context  for  a  group  of  capabilities.  The  purpose  of  a  CV-1  is  to  provide  a 
strategic  context  for  the  capabilities  described  in  the  Architectural 
Description.  It  also  provides  a  high-level  scope  for  the  Architectural 
Description  which  is  more  general  than  the  scenario-based  scope  defined 
in  an  OV-1. 

The  intended  usage  is  communication  of  the  strategic  vision  regarding 
capability  development.  (Deputy  Chief  Information  Officer  2010,  1 17) 

The  CV-I  for  the  SCMM  system  lists  the  capabilities  of  the  system,  the  overall 
system  goals,  the  desired  outcomes,  and  how  those  outcomes  are  measured.  The 
capabilities  for  the  SCMM  system  are  “convert  (or  process)  inputs  into  information  to  be 
used  for  sparing  of  parts  at  various  locations  to  support  use  case  scenarios”  and  “allow 
the  users  to  conduct  sensitivity  analyses  based  on  the  inputs  for  trade-off  analysis  for 
cost,  operational  availability  (Ao),  personnel  requirements,  weight,  and/or  space.”  The 
goals  are  to  obtain  information  and  recommendations  of  parts  allocation  to  meet  or 
increase  Ao  and  to  meet  or  decrease  budget/cost.  The  desired  outcome  is  to  support 
program  specific  documented  key  performance  parameters  and  key  system  attributes 
through  parts  allocation.  Measurable  benefits  include  Ao  (through  mean  logistics  delay 
time  [MLDT])  and  budget/costs. 

The  CV-1,  Figure  42  displays  how  the  system  intends  to  meet  the  goals:  The 
SCMM  model  is  used  on  the  user’s  hosting  platform;  it  receives  inputs  from  the  users  and 
obtains  necessary  data  from  external  databases.  The  output  from  the  system  is  in  the  form 
of  report  that  includes  information  and  recommendations  of  parts  allocation  to  the  users 
to  support  program  specific  documented  key  performance  parameters  (KPPs)  and  key 

system  attributes  (KSAs).  The  system  can  also  perform  sensitivity  analyses  based  on  the 
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user’s  needs  in  regards  to  cost,  Ao,  personnel  requirements,  weight,  and/or  space.  Based 
on  the  report,  the  users  allocate  parts  to  homeports,  maintenance  facilities,  operational 
ships,  mission  module  container,  and  outside  the  continental  United  States  (OCONUS) 
warehouses. 

OCONUS  warehouses  store  parts  available  to  maintenance  facilities  and  deployed 
ships  on  an  as-required  basis.  Allocation  at  and  storing  of  parts  at  OCONUS  warehouses 
versus  continental  United  States  (CONUS)  warehouses  decreases  the  shipping  time  to 
deployed  ships  and  OCONUS  maintenance  facilities.  Allocation  of  these  parts  onboard 
ship,  mission  module  containers,  and  maintenance  facilities  also  decreases  the  shipping 
time  to  deployed  ships  which  should  reduce  the  MLDT  that  is  a  component  of  mean 
down  time  (MDT),  thereby  positively  impacting  the  Ao. 

The  CV-1  helped  to  convey  what  the  system  should  do  and  why,  and  how  that 
would  be  measured.  It  allowed  the  system  to  be  viewed  in  its  operational  context  so  that 
the  necessary  interfaces,  resources,  and  requirements  of  the  system  could  be  framed. 
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Capabilities: 

Convert  (or  process)  data  inputs  into 
information  to  be  used  for  sparing  of 
parts  at  various  locations  based  on 
use  case  scenarios. 

Allow  the  users  to  conduct 
sensitivity  analysis  based  on  the 
inputs  for  trade-off  analysis  for  cost, 
operational  availability  (Ao), 
personnel  requirements,  weight, 
and/or  space. 

Goals: 

Obtain  information  and 
recommendations  of  parts 
allocation  to  meet  or  increase  Ao 
and  to  meet  or  decrease  cost. 


Desired  Outcome: 

Support  program  specific 
documented  key  performance 
parameters  (KPPs)  and  key  system 
attributes  (KSAs)  through  parts 
allocation. 


Measured  Benefits:  Ao,  Budget. 


Figure  42.  SCMM  System  Capability  Vision — CV-1 
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2. 


OV-1 


The  OV-1  is  a  high-level  graphical/textual  diagram  of  the  operational  concept. 
The  Deputy  Chief  Information  Officer  defines  the  OV-1  as: 

The  OV-1  describes  a  mission,  class  of  mission,  or  scenario.  It  shows  the 
main  operational  concepts  and  interesting  or  unique  aspects  of  operations. 

It  describes  the  interactions  between  the  subject  architecture  and  its 
environment,  and  between  the  architecture  and  external  systems.  The  OV- 
1  is  the  pictorial  representation  of  the  written  content  of  the  All  Views 
l(AV-l)  Overview  and  Summary  Information.  Graphics  alone  are  not 
sufficient  for  capturing  the  necessary  architectural  data. 

The  OV-1  provides  a  graphical  depiction  of  what  the  architecture  is  about 
and  an  idea  of  the  players  and  operations  involved.  An  OV-1  can  be  used 
to  orient  and  focus  detailed  discussions.  Its  main  use  is  to  aid  human 
communication,  and  it  is  intended  for  presentation  to  high-level  decision¬ 
makers.  (Deputy  Chief  Information  Officer  2010,  142) 

The  OV-1  for  the  SCMM  system,  seen  in  Figure  43  displays  the  main  operational 
concepts  in  the  system’s  context.  The  SCMM  system  is  loaded  onto  a  user’s  host 
platform  where  the  user  can  activate  it  for  operational  use.  The  system,  via  the  host 
platform,  and  connects  to  the  global  information  grid  (GIG),  which  allows  it  to  interface 
with  external  databases.  The  databases  provide  necessary  data  that  the  system  will  use  in 
order  to  support  the  user’s  query,  based  on  a  user  defined  scenario.  Users  input  or  select 
inputs,  such  as  ship  hull  number,  budget,  etc.,  the  system  uses  the  information  from  the 
databases  to  process  the  information  via  an  algorithm,  and  it  then  provides  an  output 
report.  This  report  provides  multi-nodal  optimized  sparing/inventory  recommendations 
based  on  single  or  multi-ship/mission  scenarios  with  inputs  such  as  seaframe,  mission 
module,  geographical  location,  required  Ao,  spare  parts  budget,  and  mission  duration,  for 
example.  It  also  allows  for  trade-off  analyses  to  be  conducted  for  budget,  personnel 
requirements,  Ao,  weight,  and/or  space  constraints. 

The  OV-1  helped  to  display  the  system  in  it  operating  environment.  It  showed  the 
interactions  between  the  users,  the  system,  and  the  external  environment  and  what  the 
output  of  those  interactions  would  be. 
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Figure  43.  SCMM  System  High  Level  Operational  Concept — OV-1 


3.  OV-2 

The  OV-2,  operational  resource  flow  description,  describes  the  resource  flows 
exchanged  between  operational  activities.  The  Deputy  Chief  Information  Officer  defines 
the  OV-2  as: 

The  OV-2  DODAF-described  Model  applies  the  context  of  the  operational 
capability  to  a  community  of  anticipated  users.  The  primary  purpose  of  the 
OV-2  is  to  define  capability  requirements  within  an  operational  context. 

The  OV-2  may  also  be  used  to  express  a  capability  boundary. 

New  to  DODAF  V2.0,  the  OV-2  can  be  used  to  show  flows  of  funding, 
personnel  and  materiel  in  addition  to  information.  A  specific  application 
of  the  OV-2  is  to  describe  a  logical  pattern  of  resource  (information, 
funding,  personnel,  or  materiel)  flows.  The  logical  pattern  need  not 
correspond  to  specific  organizations,  systems  or  locations,  allowing 
Resource  Flows  to  be  established  without  prescribing  the  way  that  the 
Resource  Flows  are  handled  and  without  prescribing  solutions.  (Deputy 
Chief  Information  Officer  2010,  144) 

Figure  44  is  the  SCMM  system’s  operation  resource  flow  description  diagram.  It 
depicts  the  resource  flows  into  and  out  of  the  SCMM  system,  the  users,  the  external 
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interfaces  (databases),  and  the  eventual  resource  flows  to  external  entities.  Beginning  at 
the  bottom  of  the  figure,  the  external  databases  (ERP,  NDE:  AMPS,  failure  reporting 
database,  NDE:  CDMD-OA)  have  one-way  lines  with  arrows  going  into  the  SCMM 
system  depicting  the  resources  that  will  be  flowing  from  them  to  the  system.  Moving  up 
to  the  next  level  of  the  figure,  the  resource  flow  lines  are  depicted  as  one  way  lines  with 
arrows  showing  the  resource  flows  between  the  users  and  the  system:  User  queries  flow 
from  the  users  to  the  system  while  parts  allocation  information  and  sensitivity  analysis 
results  flow  from  the  system  to  the  user.  The  next  and  last  level  depicted  in  the  diagram 
shows  the  flow  of  resources  with  one  way  lines  with  arrows  going  from  the  users  to  the 
external  organizations  that  are  the  recipients  of  the  system  processed  resources,  once 
acted  upon  by  the  users.  The  resource  flow  lines  contain  the  parts  that  will  be  going  to 
support  the  operational  ships,  homeports,  OCONUS  warehouses,  and  shore-based 
maintenance  facilities  based  on  the  SCMM  system’s  output  to  the  users  and  the  users’ 
subsequent  review,  analysis,  and  decisions  of  that  output. 

The  OV-2  helped  to  place  the  SCMM  system  in  an  operational  context  depicting 
the  required  resources  from  each  entity.  It  also  helped  to  ensure  that  the  flow  of  resources 
was  sound  and  that  the  necessary  resources  were  accounted  for.  The  specific 
organizational  resource  flows  are  captured  in  a  matrix  that  can  be  viewed  in  the 
Additional  DODAE  Views  Information  appendix. 
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Figure  44.  SCMM  System  Operation  Resource  Flow  Description — OV-2 
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4. 


OV-3 


The  OV-3  is  the  operational  resource  flow  matrix.  This  matrix  provides  a 
description  of  the  resources  exchanged  and  the  relevant  attributes  of  the  exchanges.  The 
Deputy  Chief  Information  Officer  states  the  following: 

The  OV-3  addresses  operational  Resource  Flows  exchanged  between 
Operational  Activities  and  locations. 

Resource  Flows  provide  further  detail  of  the  interoperability  requirements 
associated  with  the  operational  capability  of  interest.  The  focus  is  on 
Resource  Flows  that  cross  the  capability  boundary. 

The  intended  usage  of  the  OV-3  includes  the  definition  of  interoperability 
requirements.  (Deputy  Chief  Information  Officer  2010,  148) 

The  matrix  developed  for  the  SCMM  system  includes  the  resources  exchanged 
and  the  high  level  requirements  pertinent  to  each. 

This  view  was  not  completed  but  is  recommended  for  future  work  to  define  the 
resource  flows  and  the  characteristics  of  the  exchanges  (Deputy  Chief  Information 
Officer  2010). 

5.  OV-4 

The  OV-4  is  the  organization  relationships  chart.  This  chart  shows  the 
organizational  relationships  among  organizations.  According  to  the  Deputy  Chief 
Information  Officer: 

The  OV-4  shows  organizational  structures  and  interactions.  The 
organizations  shown  may  be  civil  or  military.  The  OV-4  exists  in  two 
forms;  role-based  (e.g.,  a  typical  brigade  command  structure)  and  actual 
(e.g.,  an  organization  chart  for  a  department  or  agency). 

A  role-based  OV-4  shows  the  possible  relationships  between 
organizational  resources.  The  key  relationship  is  composition,  i.e.,  one 
organizational  resource  being  part  of  a  parent  organization.  In  addition  to 
this,  the  architect  may  show  the  roles  each  organizational  resource  has, 
and  the  interactions  between  those  roles,  i.e.,  the  roles  represent  the 
functional  aspects  of  organizational  resources.  There  are  no  prescribed 
resource  interactions  in  DODAF  V2.0:  the  architect  should  select  an 
appropriate  interaction  type  from  the  DM2  or  add  a  new  one.  Interactions 
illustrate  the  fundamental  roles  and  management  responsibilities,  such  as 

103 


supervisory  reporting,  Command  and  Control  (C2)  relationships, 
collaboration  and  so  on. 

An  actual  OV-4  shows  the  structure  of  a  real  organization  at  a  particular 
point  in  time,  and  is  used  to  provide  context  to  other  parts  of  the 
architecture  such  as  AV-1  and  the  CVs. 

The  intended  usage  of  the  role-based  OV-4  includes: 

•  Organizational  analysis. 

•  Definition  of  human  roles. 

•  Operational  analysis. 

The  intended  usage  of  the  actual  OV-4  includes: 

•  Identify  architecture  stakeholders. 

•  Identify  process  owners. 

•  Illustrate  current  or  future  organization  structures.  (Department  of  Defense 
2010,  150) 

This  view  was  not  completed  but  is  recommended  for  future  work.  The  role-based 
OV-4  should  be  selected  to  show  the  relationships  between  the  organizational  resources 
of  the  SCMM  system. 

6.  OV-5b 

The  OV-5b  is  the  operational  activity  model,  depicting  the  operational  activities 
and  their  relationship  with  the  inputs  and  outputs  of  the  system.  The  Deputy  Chief 
Information  Officer  defines  the  OV-5b  as: 

...OV-5b  describe[s]  the  operations  that  are  normally  conducted  in  the 
course  of  achieving  a  mission  or  a  business  goal.  It  describes  operational 
activities  (or  tasks);  Input/Output  flows  between  activities,  and  to/from 
activities  that  are  outside  the  scope  of  the  Architectural  Description. 

...OV-5b  describes  the  operational  activities  that  are  being  conducted 
within  the  mission  or  scenario. 

. . .  OV-5b  can  be  used  to: 

•  Clearly  delineate  lines  of  responsibility  for  activities  when  coupled  with 
OV-2. 

•  Uncover  unnecessary  Operational  Activity  redundancy. 
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•  Make  decisions  about  streamlining,  combining,  or  omitting  activities. 

•  Define  or  flag  issues,  opportunities,  or  operational  activities  and  their 
interactions  (information  flows  among  the  activities)  that  need  to  be 
scrutinized  further. 

•  Provide  a  necessary  foundation  for  depicting  activity  sequencing  and 
timing  in  the  OV-6a  Operational  Rules  Model,  the  OV-6b  State  Transition 
Description,  and  the  OV-6cEvent-Trace  Description.  (Deputy  Chief 
Information  Officer  2010,  152) 

The  operational  activity  model — OV5b — for  the  SCMM  system  can  be  seen  in 
Figure  45.  Beginning  from  left  to  right,  it  shows  the  operational  activities  that  the  user 
performs  with  the  SCMM  system.  Above  the  operational  activities  are  the  inputs  with 
arrows  going  into  the  applicable  activity.  Below  the  activities  can  be  found  the  outputs 
from  an  activity,  depicted  with  a  one-way  arrow. 

The  OV-5b  for  the  SCMM  system  was  used  to  show  how  the  user  would  operate 
the  system  and  what  the  inputs  to  and  outputs  from  a  particular  operational  activity  would 
be.  It  showed  the  team  that  operational  redundancy  was  not  apparent  and  that  there  were 
not  any  interaction  issues  that  needed  further  scrutiny.  The  OV-5b  was  also  used  to  depict 
the  use  case  scenarios  previously  discussed  in  the  Functional  Analysis  section  of  the 
Needs  Analysis  chapter. 
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7. 


SV-1 


The  SV-1,  system  interface  description  model  identifies  the  system,  system  items, 
and  their  interconnections.  The  Deputy  Chief  Information  Officer  states  the  following: 

The  SV-1  addresses  the  composition  and  interaction  of  Systems.  For 
DODAF  V2.0,  the  SV-1  incorporates  the  human  elements  as  types  of 
Performers  -  Organizations  and  Personnel  Types. 

The  SV-1  links  together  the  operational  and  systems  architecture  models 
by  depicting  how  Resources  are  structured  and  interact  to  realize  the 
logical  architecture  specified  in  an  OV-2  Operational  Resource  Flow 
Description.  A  SV-1  may  represent  the  realization  of  a  requirement 
specified  in  an  OV-2  Operational  Resource  Flow  Description  (i.e.,  in  a 
“To-Be”  architecture),  and  so  there  may  be  many  alternative  SV  models 
that  could  realize  the  operational  requirement.  Alternatively,  in  an  “As-Is” 
architecture,  the  OV-2  Operational  Resource  Flow  Description  may 
simply  be  a  simplified,  logical  representation  of  the  SV-1  to  allow 
communication  of  key  Resource  Flows  to  non-technical  stakeholders. 

A  System  Resource  Flow  is  a  simplified  representation  of  a  pathway  or 
network  pattern,  usually  depicted  graphically  as  a  connector  (i.e.,  a  line 
with  possible  amplifying  information).  The  SV-1  depicts  all  System 
Resource  Flows  between  Systems  that  are  of  interest.  Note  that  Resource 
Flows  between  Systems  may  be  further  specified  in  detail  in  SV-2 
Systems  Resource  Flow  Description  and  SV-6  Systems  Resource  Flow 
Matrix. 

Sub-System  assemblies  may  be  identified  in  SV-1  to  any  level  (i.e.,  depth) 
of  decomposition  the  architect  sees  fit.  SV-1  may  also  identify  the 
Physical  Assets  (e.g..  Platforms)  at  which  Resources  are  deployed,  and 
optionally  overlay  Operational  Activities  and  Locations  that  utilize  those 
Resources.  In  many  cases,  an  operational  activity  and  locations  depicted  in 
an  OV-2  Operational  Resource  Flow  Description  model  may  well  be  the 
logical  representation  of  the  resource  that  is  shown  in  SV-1. 

The  intended  usage  of  the  SV-1  includes: 

•  Definition  of  System  concepts. 

•  Definition  of  System  options. 

•  System  Resource  Flow  requirements  capture. 

•  Capability  integration  planning. 

•  System  integration  management. 
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•  Operational  planning  (capability  and  performer  definition). 

The  SV-1  is  used  in  two  complementary  ways: 

•  Describe  the  Resource  Flows  exchanged  between  resources  in  the 
architecture. 

•  Describe  a  solution,  or  solution  option,  in  terms  of  the  components  of 
capability  and  their  physical  integration  on  platforms  and  other  facilities. 
(Deputy  Chief  Information  Officer  2010,  204) 

The  SV-1  for  the  SCMM  system  depicts  the  flow  of  resources  between  the 
systems  of  interest,  including  the  users  of  the  system.  Figure  46  has  several  boxes  that 
surround  the  system  box,  noted  as  “SCMM.”  The  SCMM  box  is  partitioned  into  two 
areas:  “user  inputs”  and  “repository.”  The  surrounding  boxes  have  arrows  denoting  the 
flow  of  information  from  them  to  the  partitioned  areas  of  the  SCMM  system.  The 
information  (resources)  that  flows  into  the  “repository”  area  is  shown  with  a  one-way 
arrow  that  comes  from  the  external  databases  which  push  data  into  the  system.  This  data 
is  then  integrated  into  the  system’s  repository  and  made  available  to  the  SCMM  system 
when  needed.  The  information  that  flows  into  the  “user  inputs”  area  is  depicted  with  a 
one-way  arrow  that  comes  from  the  users  (users  enter  data  into  the  system  in  order  to 
obtain  the  necessary  output).  The  one  way  arrow  from  the  system  to  the  user  depicts  the 
output  that  the  system  provides  to  the  user.  (The  output  is  a  report  that  provides  multi- 
nodal  optimized  sparing/inventory  recommendations  based  on  single  or  multi¬ 
ship/mission  scenarios,  see  the  scenarios  described  in  the  Functional  Analysis  section  of 
the  Needs  Analysis  chapter.)  The  two-way  arrow  within  the  box  depicts  how  the  system 
uses  the  external  information  flows:  the  “user  inputs”  are  used  as  filters  to  obtain  the 
pertinent  information  from  the  “repository”;  the  “repository”  makes  this  information 
available  to  the  system  to  process  and  then  outputs  a  report  that  contains  the  spare  parts 
recommendations  based  on  a  use  case  scenario. 
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Figure  46.  SCMM  System  System  Interface  Description  Model — SV-1 


8.  SV-4 

The  SV-4  diagram  is  a  systems  functionality  description  that  depicts  the  functions 
performed  by  the  system  and  the  system  data  flow  among  the  functions.  The  Deputy 
Chief  Information  Officer  defines  the  SV-4  as: 

The  SV-4  addresses  human  and  system  functionality.  The  primary 

purposes  of  SV-4  are  to: 

•  Develop  a  clear  description  of  the  necessary  data  flows  that  are  input 
(consumed)  by  and  output  (produced)  by  each  resource. 

•  Ensure  that  the  functional  connectivity  is  complete  (i.e.,  that  a  resource’s 
required  inputs  are  all  satisfied). 

•  Ensure  that  the  functional  decomposition  reaches  an  appropriate  level  of 
detail. 
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The  systems  functionality  description  provides  detailed  information 

regarding  the: 

•  Allocation  of  functions  to  resources. 

•  Flow  of  resources  between  functions. 

The  SV-4  is  the  systems  viewpoint  model  counterpart  to  the  OV-5b 

activity  model  of  the  operational  viewpoint. 

The  intended  usage  of  the  SV-4  includes: 

•  Description  of  task  workflow. 

•  Identification  of  functional  system  requirements. 

•  Functional  decomposition  of  systems. 

•  Relate  human  and  system  functions.  (Deputy  Chief  Information  Officer 
2010,211) 

Figure  47  displays  the  SV-4,  in  its  entirety,  for  the  SCMM  system.  This  figure  is 
shown  in  segments  for  readability  in  the  subsequent  graphics  with  a  brief  description  of 
each.  The  SV-4  contains  the  functions  of  the  SCMM  system  as  determined  during  the 
functional  analysis  (described  in  the  Functional  Analysis  section  of  the  Needs  Analysis 
chapter).  It  also  includes  the  flow  of  resources  between  the  functions.  The  SV-4  was 
developed  during  the  functional  analysis  of  the  system,  allowing  for  identification  of  the 
functional  system  requirements  and  the  functional  decomposition  of  the  system.  It  helped 
to  “ensure  that  the  functional  connectivity  [was]  complete”  and  that  “the  functional 
decomposition  reached  an  appropriate  level  of  detail,”  as  prescribed  by  the  Deputy  Chief 
Information  Officer  (2010,  21 1). 

Following  is  a  description  of  this  figure  and  the  subsequent  ones.  The  rectangular 
boxes  depict  the  functions  and  sub-functions  of  the  system.  Each  has  arrows  that  show 
the  flow  of  the  functions.  The  resource  flows  are  shown  as  text  with  a  line  leading  into 
the  arrows.  The  items  found  in  circles  denote  the  following: 

•  “AND”:  concurrent  function 

•  “LP”:  loop;  repeated  until  a  specific  objective  has  been  achieved 

•  “LE”:  loop  end;  the  end  of  the  loop 

•  “OR”:  does  otherwise;  used  to  link  two  or  more  alternatives 
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Figure  47.  SCMM  System  Systems  Functionality  Description — SV-4 


no 


Figure  48  displays  the  functions  and  sub-functions  of  function  1 :  enable  graphic  user  interface  with  the  resource  flows  between 
the  functions. 
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Figure  48. 


SCMM  System  Systems  Functionality  Description — Function  1:  Enable  Graphic  User  Interface 
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Figure  49  displays  the  functions  and  sub-functions  of  function  2:  receive  data  with  the  resource  flows  between  the  functions. 
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Figure  49.  SCMM  System  Systems  Functionality  Description — Function  2:  Receive  Data 
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Figure  50  displays  the  functions  and  sub-functions  of  function  3:  process  data  with  the  resource  flows  between  the  functions. 
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Figure  50.  SCMM  System  Systems  Functionality  Description — Function  3:  Process  Data 
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Figure  51  displays  the  functions  and  sub-functions  of  function  4:  provide  output  with  the  resource  flows  between  the  functions. 
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Figure  51.  SCMM  System  Systems  Functionality  Description — Function  4:  Provide  Output 
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Figure  52  displays  the  functions  and  sub-functions  of  function  5:  maintain  system  with  the  resource  flows  between  the 
functions. 


Figure  52. 


SCMM  System  Systems  Functionality  Description — Function  5:  Maintain  System 
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Figure  53  displays  the  funetions  and  sub-funetions  of  funetion  6:  seeure  system 
with  the  resouree  flows  between  the  funetions. 


Figure  53.  SCMM  System  Systems  Funetionality  Deseription — Funetion  6:  Seeure 

System 


9.  SV-5a 

The  SV-5a  is  the  operational  aetivity  to  system  function  traceability  matrix,  which 
provides  a  mapping  of  the  operational  activities  to  the  system  functions.  The  Deputy 
Chief  Information  Officer  defines  the  SV-5a  as  follows: 
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The  SV-5a  addresses  the  linkage  between  System  Functions  described  in 
SV-4  Systems  Functionality  Description  and  Operational  Activities 
specified  in...OV-5b  Operational  Activity  Model.  The  SV-5a  depicts  the 
mapping  of  system  functions  and,  optionally,  the  capabilities  and 
performers  that  provide  them  to  operational  activities.  The  SV-5a 
identifies  the  transformation  of  an  operational  need  into  a  purposeful 
action  performed  by  a  system  or  solution. 

During  requirements  definition,  the  SV-5a  plays  a  particularly  important 
role  in  tracing  the  architectural  elements  associated  with  system  function 
requirements  to  those  associated  with  user  requirements. 

•  The  intended  usage  of  the  SV-5a  includes: 

•  Tracing  functional  system  requirements  to  user  requirements. 

•  Tracing  solution  options  to  requirements. 

•  Identification  of  overlaps  or  gaps.  (Deputy  Chief  Information  Officer 
2010,  213) 

Table  9  captures  the  mapping  of  the  SCMM  system’s  operational  activities  to  its 
system  functions.  This  mapping  allowed  the  team  to  ensure  that  there  was  a  system 
function  to  perform  an  identified  operational  need.  It  also  served  to  illustrate  that  there 
were  not  any  overlaps  or  gaps  in  the  designed  system. 
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Operational  Activity 

Number 

Function 

A  1.0 
Launch 
System 

A  2.0 

Enter  Login 
Information 

A  3.0 
Execute 
Login 

A  4.0 
Enter 
Inputs  / 
Selection 

A  5.0 
Execute 
System 

A  6.0 
Assess 
Results 

A  7.0 
Log 
Off 

1 

Enable  Graphic  User  Interface 
(GUI) 

X 

X 

X 

1.1 

Display  Log-in  Screen 

X 

X 

X 

1.1.1 

Accept  User  Name  and 
Password 

X 

X 

1.2 

Perform  Login  Credential 
Security  Verification 

X 

1.2.1 

Invalidate  Password 

X 

1.2.2 

Invalidate  User  Name 

X 

1.2.3 

Validate  Username  and 
Password 

X 

1.3 

Display  GUI 

X 

X 

X 

X 

X 

1.4 

Enable  data  entry/selection 
fields 

X 

X 

2 

Receive  Data 

X 

2.1 

Accept  User  Input/Selected 
Data 

X 

2.1.1 

Verify  User  Input/Selected 

Data 

X 

2.1. 1.1 

Invalidate  User  Inputs 

X 

2.1. 1.2 

Validate  User  Inputs 

X 
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Operational  Activity 

2.2 

Accept  Data  from  External 
Databases 

X 

2.2.1 

Verify  Data  Integrity 
(Complete/Correct/Does  Not 
Contain  Errors) 

X 

2.2.1. 1 

Invalidate  Database  Data 

X 

2.2.1.2 

Validate  External  Database 
Data 

X 

2.2.2 

Integrate  the  data  into 
repository 

X 

2.2.3 

Save  Data  in  System 

Repository 

X 

3 

Process  Data 

X 

3.1 

Process  Request 

X 

3.2 

Execute  Query 

X 

3.3 

Verify  Query  Requirements 

Are  Being  Met 

X 

3.3.1 

Invalidate  Query 

X 

3.3.2 

Validate  Query 

X 

3.4 

Obtain  Eiltered  Data  Erom 
Repository 

X 

3.5 

Perform  Sparing  Analysis 

X 

4 

Provide  Output 

X 

X 
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Operational  Activity 

4.1 

Display  Sparing  Results 
(Graphical  Output  Based  on 
User’s  Query) 

X 

4.1.1 

Save  Sparing  Results 

X 

4.1.2 

Print  Sparing  Results 

X 

4.1.3 

Perform  Sensitivity  Analysis 

X 

X 

X 

4.1.4 

Delete  Results 

X 

5 

Maintain  System 

X 

X 

X 

X 

X 

5.1 

Execute  System  Self  Check 

X 

X 

X 

X 

X 

5.1.1 

Execute  Repository  Check 

X 

X 

X 

X 

X 

5.1.2 

Execute  Interface  Check 

X 

X 

X 

X 

X 

5. 1.2.1 

Execute  System  Side  Check 
of  Interface 

X 

X 

X 

X 

X 

5. 1.2.2 

Execute  External  Database 
Check  of  Interface 

X 

X 

X 

X 

X 

5.1.2.2.1 

Display  External  Database 
Status 

X 

X 

X 

X 

X 

5.1.3 

Execute  Processes  Check 

X 

X 

X 

X 

X 

5.2 

Provide  Maintenance  History 

X 

X 
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Operational  Activity 

5.2.1 

Display  Time/Date  of  Last 

Data  Download 

X 

X 

5.2.2 

Display  Last  Login 

Information 

X 

X 

6 

Secure  System 

X 

X 

X 

X 

X 

X 

X 

6.1 

Ensure  Information  Assurance 
Compliance 

X 

X 

X 

X 

X 

X 

X 

6.2 

Secure  the  GUI 

X 

X 

X 

X 

X 

X 

X 

6.3 

Secure  Login  Process 

X 

X 

X 

X 

X 

X 

X 

6.4 

Secure  Repository 

X 

X 

X 

X 

X 

X 

X 

6.5 

Secure  the  Interfaces  with 
External  Databases 

X 

X 

X 

X 

X 

X 

X 

Table  9.  SCMM  System  Operational  Activity  to  System  Function  Traceability  Matrix — SV-5a 


121 


C.  SUMMARY 

The  system  architecture  phase  of  team  RSRP’s  tailored  vee  captured  the  logical 
sequencing  and  interaction  of  system  functions  within  a  model  based  systems  engineering 
architecture  based  on  DODAF  v2.02  principles.  DODAF  views  were  used  in  the 
construction  of  the  system  architecture  to  ensure  consistency  when  describing  the  system 
components,  functions,  boundaries,  and  interactions.  The  SCMM  system  capabilities  and 
relationships  were  documented  with  capability,  operational,  and  system  views  to  develop 
a  high  level  system  design  to  meet  the  stakeholders’  needs. 

A  CV-1  diagram  was  developed  using  Microsoft  PowerPoint  to  help  establish  the 
system  capabilities  and  illustrate  the  strategic  context  of  the  system.  The  CV-1  not  only 
illustrated  what  the  desired  system  capabilities  are  for  the  SCMM  system  but  also  showed 
how  the  system  would  satisfy  these  goals.  The  CV-1  gives  a  high  level  view  of  what  the 
system  interfaces  are  in  an  operational  context  and  why  the  system  should  function  in  this 
way  to  provide  the  determined  outputs. 

The  operational  views  that  were  constructed  for  the  system  architecture  were  the 
OV-1,  OV-2,  and  OV-5b.  The  OV-1,  which  is  the  high  level  graphical  diagram  of  the 
system’s  operational  concept,  was  developed  to  show  the  interactions  of  the  SCMM 
system  within  its  intended  environment  and  external  systems.  The  OV-1  illustrated  the 
dependence  on  external  databases  to  provide  the  user  with  relevant  data  for  optimal  parts 
sparing  based  on  defined  inputs.  The  OV-2  gave  a  description  of  the  resource  flows 
between  operational  activities.  It  depicts  the  resource  flows  into  and  out  of  the  SCMM 
system,  the  users,  the  external  interfaces  (databases),  and  the  eventual  resource  flows  to 
external  entities.  The  development  of  the  OV-2  ensured  the  accountability  of  resources 
exchanged  between  entities  internal  and  external  to  the  SCCM.  The  creation  of  the  OV- 
5b  was  to  show  interaction  of  the  operational  activities  with  the  inputs  and  outputs  of  the 
SCMM  system.  It  was  used  to  highlight  any  redundancy  apparent  within  the  architecture 
of  the  system  and  to  validate  the  use  case  scenarios. 

The  system  views  constructed  for  the  SCMM  architecture  were  the  SV-1,  SV-4, 


and  SV-5a.  The  SV-1  was  used  to  identify  the  interconnections  with  the  established 
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system  and  system  resources  to  conceive  the  resource  flows  depicted  in  the  OV-2.  The 
SV-4  illustrated  the  functions  performed  by  the  system  and  the  data  flow  between  the 
functions.  Concurrent  diagrams  were  created  showing  the  detailed  data  flow  between  the 
functions  determined  in  the  functional  analysis  phase:  enable  graphic  user  interface, 
receive  data,  process  data,  provide  output,  maintain  system,  and  secure  system.  The  SV- 
5a  was  developed  to  map  the  operational  activities  to  the  system  functions  via  a 
traceability  matrix.  The  matrix  identified  a  system  function  to  perform  a  determined 
operational  need  of  the  SCMM  and  ensured  the  coverage  of  gaps  by  the  designed  system. 

The  development  of  the  system  architecture  ensured  traceability  to  the  system 
requirements  and  established  a  roadmap  for  the  conceptual  design  of  the  system  while 
ensuring  coverage  of  the  stakeholders’  needs. 
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V.  CONCEPTUAL  DESIGN 


The  purpose  of  this  phase  was  to  identify  a  system  design  that  met  the  functional 
and  performance  requirements  of  the  system.  A  conceptual  design  was  created  in 
conjunction  with  system  analysis  by  conducting  an  AoA.  This  phase  was  used  to  narrow 
down  the  best  alternative  to  meet  the  needs  of  the  stakeholders/sponsor.  The  AoA  was 
conducted  using  the  requirements  identified  during  the  functional  and  system 
requirements  analyses.  These  include  the  operational,  input/output,  and  functional 
requirements. 

A.  ANALYSIS  OF  ALTERNATIVES 

The  AoA  methodology  was  used  to  identify  potential  solutions  that  could  satisfy 
the  requirements  and  support  a  decision  based  on  the  most  effective  solution.  The  AoA 
identifies  a  wide  range  of  solutions  that  have  a  reasonable  likelihood  of  providing  the 
needed  capability  for  the  defined  requirements  (Department  of  Defense  2013). 

The  following  questions  were  answered  by  the  AoA: 

•  Do  the  alternatives  meet  the  requirements? 

•  Are  the  alternatives  operationally  effective  and  suitable? 

•  Can  they  be  supported? 

•  What  are  the  risks  and  costs  for  each  alternative? 

The  AoA  is  a  key  factor  in  selecting  a  final  solution,  but  it  is  not  the  only  factor. 
The  final  decision  must  consider  not  only  the  criteria/requirements  but  also  domestic 
policy,  technological  maturity  of  the  solution,  the  environment,  and  the  budget  (Office  of 
Aerospace  Studies  2008). 

Because  of  fielding  and  implementation  time  constraints  for  the  SCMM  system, 
the  primary  purpose  of  this  AoA  was  to  find  an  existing  model  that  could  provide  the 
right  spare  in  the  right  place  to  meet  and/or  improve  the  operational  availability  (Ao)  of 
modular  or  flexible  class  ships  using  the  criteria  of  space,  weight,  cost,  criticality,  multi- 
nodal,  and  multi-mission  input  capability,  as  approved  by  the  sponsor.  The  team  made 
several  assumptions  during  the  AoA  analysis: 
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•  Cost  associated  with  increasing  the  Ao  was  not  a  factor  in  the  selection 
process. 

•  All  reviewed  models  can  be  re -programmed  to  meet  the  SCMM  system’s 
requirements. 

•  None  of  the  models  are  proprietary. 

•  The  model  seleeted  will  be  made  available  to  be  re-programmed;  and  will 
become  either  a  new  system  or  the  next  version  of  the  existing  system. 

These  assumptions  were  necessary  so  that  the  team  could  complete  this  analysis 
within  the  required  timeframe.  The  team  made  these  assumptions  for  the  AoA  analysis 
only,  and  they  were  not  applicable  to  other  sections  of  this  project. 

The  AoA  process  included  a  swing  weighting  assessment  methodology  adapted 
from  Making  Hard  Decisions  with  Decision  Tools  (Clemen  and  Reilly  2001).  The  swing 
weighting  assessment  direetly  compares  the  individual  criteria  against  each  model.  The 
assessment  process  is  described  in  more  detail  in  the  Analysis  of  Existing  Systems 
section  of  this  chapter. 

1.  Determining  the  Alternatives 

The  team  researched  and  discussed  many  potential  solutions  to  the  problem. 
Three  primary  options  were  identified  as  follows: 

a.  Option  1 

Do  nothing — maintain  the  current  modular  or  flexible  design  ship  parts  sparing 
methodology.  Using  the  ECS  class  ships  as  an  example,  the  current  process  is  for  the 
original  equipment  manufacturers  (OEM)  to  provide  a  list  of  recommended  spare  parts. 
This  created  a  problem  beeause  the  initial  spare  parts  proposals  exceeded  the  allowable 
shipboard  space  and  weight  constraints.  In  order  to  support  early  deployment,  the  list  was 
reduced  by  subject  matter  experts  (SMEs)  without  use  of  any  analytical  techniques  to 
justify  the  reduction  of  parts. 

b.  Option  2 

Modify  existing  DOD  part  sparing  models/tools  to  accommodate  all  of  the 
SCMM  system  requirements,  which  includes  the  space  and  weight  limitations  of  the  ship 
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to  support  the  multi-nodal  infrastructure  and  multi-mission  operational  scenarios  of 
modular  or  flexible  design  ships.  According  to  Blanchard  and  Fabrycky,  “...it  is 
necessary  to  (1)  identify  various. ..alternatives  that  could  be  pursued  in  response  to  the 
need;  [and]  (2)  evaluate  the  most  feasible  approaches  to  find  the  most  desirable  in  terms 
of  performance,  effectiveness,  maintenance  and  sustaining  support,  and  life-cycle 
economic  criteria...”  (Blanchard  and  Fabrycky  2011,  60).  There  are  many  existing 
models  that  might  be  sufficient  to  address  a  majority  of  the  requirements.  But,  as 
Blanchard  and  Fabrycky  state,  “...the  number  of  these  must  be  narrowed  down  to  those 
that  are  physically  feasible  and  realizable  within  schedule  requirements  and  available 
resources”  (Blanchard  and  Fabrycky  2011,  60). 

c.  Option  3 

Develop  a  new  system  to  optimize  part  sparing  based  on  the  space  and  weight 
constraints  of  the  ship  to  support  the  required  multi-nodal  infrastructure  and  multi¬ 
mission  operational  scenarios  of  modular  or  flexible  design  ships. 

After  discussing  these  options  with  the  sponsor,  option  2  was  determined  to  be  the 
most  feasible  and  was  selected  for  further  research  and  analysis.  Option  1  was  deemed  as 
not  an  acceptable  solution  to  the  problem;  the  current  parts  sparing  process  was 
determined  to  be  not  acceptable  during  the  literature  review  segment  of  this  capstone 
project.  Option  3  was  assumed  to  be  time  consuming  and  costly  because  the  development 
of  a  new  system  has  to  begin  from  very  early  system  advance  planning  and  architecting 
after  the  problem  has  been  defined  and  the  need  has  been  identified,  which  have  already 
been  performed  during  the  course  of  this  project  (Blanchard  and  Fabrycky  2011).  Option 
2  was  then  considered  to  be  the  most  reasonable  based  on  the  availability  of  current  DOD 
parts  sparing  models  and  the  community’s  willingness  to  adapt  these  to  meet  current 
and/or  future  needs,  as  described  in  the  Literature  Review  section  of  this  report  in  the 
Needs  Analysis  chapter. 

2.  Analysis  of  Existing  Systems 

The  analysis  for  option  2  was  based  on  the  initial  research  conducted  in  2013  by 
Ms.  Breanna  Newton,  a  logistics  intern  working  for  NSWC  PHD  Land  Attack- 

127 


Department.  She  was  given  a  list  of  various  models  from  the  different  services  (Air 
Force,  Army  and  Navy),  by  the  team’s  current  sponsor,  Mr.  Howard,  to  assist  with  her 
efforts  for  her  intern  senior  project.  This  list  of  models  was  created  based  on  the  models’ 
inclusion  of  software,  analytical  techniques,  processes,  logistics  footprint,  and  path  for 
decisions.  A  list  with  a  total  of  406  models  was  provided  to  her,  which  she  initially 
reviewed  and  scaled  down  to  201  for  further  comparison.  The  scaling  criteria  used  were 
that  the  models  had  to  be  related  to  supply  support  or  parts  sparing. 

She  then  compared  the  201  models  on  the  list  and  excluded  those  that  did  not 
include  operational  availability  impacts  and  cost  tradeoff  assessment  capabilities.  Based 
on  this  very  high  level  assessment  the  list  was  further  down  selected  to  22  tools  (B. 
Newton,  unpublished  data).  The  team  used  this  list  of  models  to  conduct  the  AoA.  In 
addition,  a  new  tool  called  OPUS  10  was  added  to  the  list  after  determining  it  could  be  a 
potential  solution  to  the  parts  sparing  problem.  The  models  reviewed  for  the  AoA  are 
included  in  Table  10. 


Model  Name 

Acronym 

Service 

Availability  Centered  Inventory  Model 

ACIM 

Navy 

Aegis  Optimization  Model 

AOM 

Navy 

Automatic  Requirements  Computation 
System  Initial  Provisioning 

ARCSIP 

Army 

Aviation  Readiness  Requirements 
Oriented  to  Weapon  Replaceable 
Assemblies 

ARROWS 

Navy 

Aircraft  Sustainability  Model 

ASM 

Air  Eorce 

BlockSim 

BLOCKSIM 

Multiple 

Customer  Oriented  Leveling  Techniques 

COLT 

Air  Eorce 

Computerized  Optimization  Model  for 
Predicting  and  Analyzing  Support 
Structure 

COMPASS 

Multiple 

Fleet  Logistics  Support  Improvement 
Program 

FLSIP 

Navy 

Logistics  Composite  Model 

LOOM 

Air  Eorce 

Logistics  Analysis  Model 

LOGAM 

Army 

Multi-Echelon  Readiness  Based  Sparing 

ME-RBS 

Navy 

Software  tool  in  Opus  Suite  System 

OPUS  10 

Multiple 

Optimum  Stock  Requirements  Analysis 
Program 

OSRAP 

Army 
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Model  Name 

Acronym 

Service 

Quanterion  Automated  Reliability 

Toolkit 

QUART 

Navy 

RAPTOR 

RAPTOR 

Multiple 

Readiness  Based  Eeveling  (RBE) 

RBE 

Air  Eorce 

ReliaSoft 

REEIASOET 

Multiple 

Support  Enterprise  Model 

SEM 

Army 

Selectable  Essential  Item  Stock  and 
Availability  Method 

SESAME 

Army 

System  of  Systems  Analysis  Tool  Set 

SoSAT 

Multiple 

Service  Planning  and  Optimization 

SPO 

Navy 

TIGER- Availability  Centered  Inventory 
Model 

TIGER-ACIM 

Navy 

Table  10.  List  of  the  22  Existing  Models  for  Swing  Weight  Evaluation 


In  order  to  evaluate  these  23  models,  the  team  used  the  linear  combination  of 
weighting  methodology  to  evaluate  them  as  discussed  in  the  paper  Quantitative  Methods 
for  Tradeoff  Analyses  (Daniels,  Werner  and  Bahill  2001).  Six  criteria  were  derived  from 
the  SCMM  system’s  requirements  that  were  determined  to  have  a  significant  effect  on  the 
model  alternatives  under  evaluation.  These  selected  criteria  were  independent  of  each 
other  so  “preference  order  and  the  trade-off  for  different  levels  of  the  criteria  do  not 
depend  on  the  levels  at  which  all  other  criteria  occur”  (Blanchard  and  Eabrycky  2011, 
181).  The  sponsor  assessed  and  agreed  with  the  selected  criteria  and  he  assigned  equal 
weighting  (equal  importance)  to  them.  A  weight  is  used  to  establish  the  importance  of  the 
criteria  in  the  overall  evaluation  of  the  alternatives  (Daniels,  Werner  and  Bahill  2000).  A 
criterion  with  a  higher  importance  is  given  more  weight  (Daniels,  Werner  and  Bahill 
2001).  Since  the  sponsor  specified  equal  weighting  of  the  six  criteria,  each  criterion  was 
assigned  a  weight  of  1/6  for  the  evaluation — the  weights  need  to  add  to  one.  Table  11 
displays  the  criteria  and  assigned  weight. 


Criteria 

Weight 

Space  input 

0.1667 

Weight  input 

0.1667 

Operational  Availability  input 

0.1667 

Cost  input 

0.1667 

Multi-Nodal  input 

0.1667 
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Criteria 

Weight 

Multi-Mission  input 

0.1667 

Sub-total 

1.0000 

Table  1 1 .  Swing  Weight  Criteria 


Figure  54  shows  how  the  initial  406  models  were  down-selected  to  23  models;  the 
swing  weighting  method  was  then  used  to  identify  the  top  alternatives. 


Prior 


Ao  &  Cost  trade>ofr  assessment 
capabilities  used  to  do>^’n  select 
201  to  22  models 


Supply  or 

sparing 

model? 


Swing  weight 
Linear 

Combination 


Multi-Nodal? 

Multi-Mission? 


Research 


406  Models 


OPUS  10 


Space? 

Weight? 

Ao? 

Cost? 


22  Models 


ME-RBS,  ARROWS.  OSRAP 


Figure  54.  Alternative  Models  Down-Selection  Process 


Each  of  the  23  models  was  evaluated  against  each  criterion  using  a  score  between 
zero  to  five.  A  model  that  completely  met  the  criteria  was  assigned  a  score  of  five.  A  zero 
score  meant  the  model  did  not  include  that  criterion.  The  resultant  score  under  each 
criterion  was  then  multiplied  by  its  corresponding  weight.  The  final  scoring  was  the 
summation  of  the  weight-times-score  for  each  criterion.  The  objective  of  this  analysis 
was  to  select  the  highest  performing  existing  system  alternatives.  An  alternative  that 
completely  met  all  six  criteria  will  have  a  final  score  of  5.  The  highest  remaining 
alternatives  would  be  further  analyzed  and  researched  in  order  to  recommend  use  of, 
modification  to,  or  new  development  of  a  model  to  meet  the  requirements  of  the 
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stakeholders.  The  specific  scores  in  each  criterion  category  can  be  found  in  the  Analysis 
of  Alternatives  Scoring  Matrix  appendix. 

Figure  55  shows  the  final  scoring  (un-sorted)  for  all  23  models. 


Total 

Model  Name 

Weight 

ACIM  (NAVY) 

0.8333 

AOM(NAVY) 

1.8333 

.ARCSIP  (ARMY) 

0.8333 

.ARROWS  (NAVY) 

2.5000 

ASM  (.AIR  FORCE) 

0.6667 

BLOCKSIM  (MULTIPLE) 

0.3333 

COLT  (AIR  FORCE) 

0.8333 

COMPASS  (MULTIPLE) 

1.1667 

FLSIP  (NAVY) 

0.5000 

LOOM  (AIR  FORCE) 

0.6667 

LOGAM(ARMY) 

0.3333 

ME-RBS  (NAVY) 

2.8333 

OPUS  10 

1.0000 

OSR.AP  (ARMY) 

2.3333 

QU.ART  (NAVY) 

0.3333 

R.APTOR  (MULTIPLE) 

1.0000 

RBL  (.AIR  FORCE) 

1.1667 

RELIASOFT  (MULTIPE) 

0.3333 

SEM(ARMY) 

0.6667 

SESAME  (ARMY) 

1.3333 

SoSAT  (MULTIPLE) 

0.5000 

SPO  (NAATD 

1.1667 

TIGER  (NAVY) 

0.6667 

0.0000  1.0000  2.0000  3.0000 


Figure  55.  Final  Swing  Weight  (Unsorted) 


Figure  56  shows  the  sorted  final  scoring  for  each  alternative.  The  alternative  that 
scored  the  highest  based  on  the  six  criteria  is  listed  first. 
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Total 

Model  Name 

Weight 

ME-RBS  (NAVY) 

2.8333 

ARROWS  (NAVY) 

2.5000 

OSRAP  (ARMY) 

2.3333 

AOM  (NAVY) 

1.8333 

SESAME  (ARMY) 

1.3333 

COMPASS  (MULTIPLE) 

1.1667 

SPO  (NAVY) 

1.1667 

RBL  (AIR  FORCE) 

1.1667 

OPUS  10 

1.0000 

RAPTOR  (MULTIPLE) 

1.0000 

ACIM  (NAVY) 

0.8333 

ARCSIP  (ARMY) 

0.8333 

COLT  (AIR  FORCE) 

0.8333 

ASM  (AIR  FORCE) 

0.6667 

LCOM  (AIR  FORCE) 

0.6667 

SEM  (ARMY) 

0.6667 

TIGER  (NAVY) 

0.6667 

FLSIP  (NAVY) 

0.5000 

SoSAT  (MULTIPLE) 

0.5000 

BLOCKSIM  (MULTIPLE) 

0.3333 

LOGAM  (ARMY) 

0.3333 

QUART  (NAVY) 

0.3333 

RELIASOFT  (MULTIPE) 

0.3333 

Figure  56.  Final  Swing  Weight  (Sorted) 


This  analysis  yielded  three  alternatives  with  the  highest  scores  for  potential 
adoption  and  modification: 

•  ME-RBS  (Navy) 

•  ARROWS  (Navy) 

•  OSRAP  (Army) 

ME-RBS  had  the  highest  score  of  2.8333,  ARROWS  had  a  final  score  of  2.5,  and 
OSRAP  had  a  final  score  of  2.3333.  As  discussed  earlier,  any  alternative  that  met  all  of 
the  criteria  would  have  a  final  scoring  of  5.0.  ME-RBS  currently  satisfied  approximately 
57  percent  of  the  criteria  requirements,  while  both  ARROWS  and  OSRAP  met 
approximately  50  of  the  criteria  requirements.  Any  other  alternative  that  satisfied  less 
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than  50  percent  of  the  criteria  requirements  would  not  be  considered  due  to  the  amount  of 
changes  required  to  accommodate  all  the  SCMM  system  requirements. 

B.  DETAILED  DESCRIPTION  OF  THE  TOP  THREE  ALTERNATIVES 

The  AoA  identified  three  alternatives  that  may  be  suitable  to  adapt  to  the  SCMM 
system  requirements. 

1.  ME-RBS:  Multi-Echelon  Readiness  Based  Sparing 

ME-RBS  is  a  Navy  RBS  tool  used  by  the  Naval  Supply  Systems  Command 
(NAVSUP)  to  achieve  a  desired  operational  availability  (Ao)  or  full  mission  capability 
(EMC)  of  weapon  systems  (CACI  2006).  This  tool  is  used  to  minimize  inventory  cost  of 
spares  while  supporting  readiness  response  time  for  parts  support  (minimizing  MEDT) 
(CACI  2006). 

ME-RBS  integrates  ARROWS,  ACIM  (Availability  Centered  Inventory  Model), 
and  TIGER  spare  models  into  its  workstation  (CACI  2006).  ME-RBS  determines  Ao  for 
readiness  (Ao/EMC)  by  calculating  the  input  data  (CACI  2006).  Input  data  such  as  mean 
time  between  failure/mean  times  to  repair  (MTBE/MTTR),  essential  missions,  funding 
constraints,  and  spares  requirements  are  processed  based  upon  engineering  criticality  for 
reliability  block  diagrams  (RBDs)  that  depict  the  effect  of  an  item’s  failure  on  a  system’s 
functional  performance  (CACI  2006).  ME-RBS  highly  focuses  on  the  evaluation  of 
weapon  system  readiness  at  optimum  Ao  with  minimum  cost  per  unit  and  reduced 
waiting  time  (CACI  2006).  ARROWS,  ACIM,  and  TIGER  are  embedded  in  ME-RBS 
imparting  the  capabilities  to  support  multi-nodal  requirements  to  support  operational 
readiness  (CACI  2006). 

2.  ARROWS:  Aviation  Readiness  Requirements  Oriented  to  Weapon 
Replaceable  Assemblies 

The  ARROWS  model  is  a  Navy  readiness  based  sparing  model  used  to  develop  a 
spare  part  inventory  list  (Strauch  n.d.).  ARROWS  uses  operational  and  logistics 
requirement  inputs  in  the  model  to  evaluate  and  to  compute  the  spare  parts  needed  to 
support  the  operational  availability  of  aviation  weapon  systems  (Strauch  n.d.). 
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The  output  parts  list  from  ARROWS  consists  of  necessary  parts  to  support  full 
mission  capability  of  weapon  systems  as  well  as  the  non-critical  mission  requirements 
(Strauch  n.d.).  ARROWS  uses  the  required  input  data  for  each  part  of  the  weapon  system 
to  compute  the  Ao  increment  along  with  the  associated  cost  (Strauch  n.d.).  It  then 
determines  the  parts  list  based  upon  the  ratio  of  Ao-cost  and  the  total  cost  and  the 
availability  of  the  weapon  systems  according  to  the  available  spare  part  stock  (Strauch 
n.d.). 

ARROWS  has  the  capability  to  process  data  for  support  of  multiple  weapon 
systems,  sites,  and  levels  of  repair  (Strauch  n.d.).  It  also  has  the  ability  to  compute  a  spare 
parts  list  based  on: 

•  critical  repairable  parts  versus  cost  and  part  availability  (Strauch  n.d.). 

•  cost  minimization  for  high  price  repairable  parts  versus  low  cost  repairable 
parts  (Strauch  n.d.). 

•  cost  effectiveness  of  available  spare  part  stock  for  critical  versus  non- 
critical  missions  (Strauch  n.d.). 

3.  OSRAP:  Optimum  Stock  Requirements  Analysis  Program 

OSRAP  was  developed  to  produce  a  part  list  to  support  the  readiness  of  Army 
weapon  systems.  For  optimal  part  requirements,  OSRAP  uses  the  following  input  data: 
unit  costs,  repairable  levels  of  parts,  time  to  repair,  and  awaiting  part  time  (Department  of 
Defense  2011). 

OSRAP  produces  the  essential  parts  list  to  guarantee  the  critical  mission 
availability  of  weapon  systems  in  consideration  of  minimizing  cost,  weight,  and  space 
while  increasing  the  operational  availability  (Department  of  Defense  2011).  It  also 
provides  the  available  stock  for  non-essential  mission  readiness  to  conserve  cost 
(Department  of  Defense  2011). 

OSRAP  focuses  on  the  mission  readiness  of  multiple  weapon  systems  along  with 
cost,  performance,  mobility,  space,  and  weight  that  can  overall  decrease  operational  cost 
and  significantly  increase  the  critical  operational  availability  due  to  the  improvement  of 
availability  of  forward  based  sparing  (Department  of  Defense  2011).  As  a  result,  it 
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reduces  the  logistic  footprint  by  the  advance  of  supply  support  in  available  repairable 
parts  (Department  of  Defense  2011). 

C.  RESULTS  OF  ANALYSIS  OF  ALTERNATIVES 

The  analysis  of  alternatives  compared  the  results  from  the  calculation  of  each 
alternative’s  multi  attributes.  Based  on  the  results,  three  alternatives,  ME-RBS, 
ARROWS,  and  OSRAP,  had  the  highest  scores  providing  the  decision  to  support  viable 
solutions  for  the  capstone  project’s  most  preferable  alternative  to  offer  improved  Ao, 
comparative  cost,  and  effective  support  to  the  current  modular  ship  configuration. 

1.  Space  and  weight  constraints 

OSRAP  was  the  only  alternative  considering  space  and  weight  in  the  process  to 
provide  a  mission  essential  part  list.  The  overall  focus  on  space  and  weight  limits  made 
OSRAP  a  serious  alternative  deserving  consideration. 

2.  Operational  availability 

All  three  alternatives  were  focused  on  optimizing  the  Ao  of  a  weapon  system.  The 
calculation  of  data  inputs  produced  a  repairable  parts  list  with  the  forecast  value  of  Ao 
that  related  to  the  supply  of  parts.  The  three  alternatives  were  at  the  same  level  in 
consideration  of  providing  a  higher  Ao  for  weapons  systems  readiness. 

3.  Cost 

All  three  alternatives  minimized  parts  cost  while  providing  a  recommended  parts 
list  to  achieve  the  best  Ao.  OSRAP  and  ARROWS  are  standalone  systems.  ME-RBS  is 
embedded  with  ARROWS,  ACIM,  and  TIGER.  ME-RBS  provides  optimized  aggregated 
spares  through  the  use  of  its  multi-echelon  capability.  This  provides  support  of  critical 
missions  based  on  weapon  system  readiness  while  minimizing  the  total  cost  of  parts 
inventory. 

4.  Multi-Nodal  and  Multi-Mission 

ME-RBS,  ARROWS,  and  OSRAP  support  multi-nodal  and  multi-mission  needs 
from  a  variety  of  input  data  sources  in  order  to  deliver  a  spare  parts  list  with  a  target  Ao. 
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ARROWS  has  the  ability  to  take  in  multi-nodal  and/or  multi-mission  data,  while  OSRAP 
could  be  modified  to  take  in  the  required  multi-nodal  or  multi-mission  criteria  as  needed. 
In  view  of  that,  these  two  alternatives  had  lower  capability  in  supporting  multi-nodal  and 
multi-mission  requirements  than  ME-RBS,  which  had  all  capabilities,  with  the  exception 
of  the  space  and  weight  requirements,  from  the  embedded  models  in  its  work  station. 

D.  SUMMARY 

The  conceptual  design  phase  consisted  of  identifying  a  system  design  to  meet  the 
functional  and  performance  requirements  of  the  SCMM  system.  To  identify  established 
and  operational  models  within  the  Department  of  Defense  (DOD)  community  for 
possible  adaptation.  Team  RSRP  used  weighted  criteria  based  on  the  SCMM  system 
requirements  to  conduct  an  analysis  of  alternatives  (AoA).  The  three  highest  scoring 
alternatives  were  further  analyzed,  and  the  benefits  and  disadvantages  of  each  were 
analyzed.  As  a  result  of  the  AoA,  it  was  determined  that  the  ME-RBS  model  appeared  to 
support  a  wide  range  of  capabilities  and  functions  including  different  methodologies  to 
calculate  allowance  parts  lists  while  potentially  improving  Ao.  Even  though  the  drawback 
is  its  limitation  in  space  and  weight  calculations,  ME-RBS  was  the  recommended 
alternative.  This  decision  was  based  on  expected  system  performance  due  to  its  abilities 
to  distribute  spare  parts  at  the  multi-nodal  (multi-echelon)  level  to  accommodate  the 
desired  Ao  and  cost  considerations,  while  accounting  for  the  multi  mission  aspect  of 
modular  or  flexible  design  ships.  The  SCMM  system  must  consider  the  constraints  of 
space  and  weight  for  these  ship  types.  Spare  parts  recommendations  are  then  calculated  to 
support  a  multi-nodal  maintenance  infrastructure  to  sustain  and/or  improve  operational 
availability,  while  taking  into  account  these  ships’  multi-mission  capability  and  parts 
support  budget. 

The  Navy  and  the  Army  each  have  readiness-based  sparing  models  that  could 
provide  some  benefits  as  the  alternative  model  for  the  SCMM  system.  The  three 
alternatives  mostly  support  the  parts  sparing  requirements  for  modular  or  flexible  design 
ships. 
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The  team  concluded  that  the  Multi-Echelon  Readiness  Based  Sparing  (ME-RBS) 
system  is  the  best  alternative  suitable  for  adaptation  to  support  the  stakeholders’  needs 
and  requirements.  This  model  requires  additional  research  to  determine  whether 
modification  is  viable  in  terms  of  design  and  cost.  Another  option  is  the  development  of  a 
new  system  rather  than  adaptation  of  an  existing  system.  This  option  would  be  preferred 
if  the  ME-RBS  system’s  design  could  not  be  altered  and/or  if  the  cost  was  above  that  of 
new  system  development.  The  team  recommends  that  research  and  analysis  continue  in 
support  of  the  development  of  the  SCMM  system,  whether  it  is  the  alteration  of  the  ME- 
RBS  system  or  the  creation  of  a  new  system,  to  meet  the  identified  stakeholders’  needs. 
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VI.  MODELING  AND  SIMULATION 


Modeling  and  Simulation  (M&S)  has  become  a  generalized  term  that  is  used  to 
define  and  demonstrate  the  system.  The  team  used  modeling  and  simulation  tools 
separately  to  model  the  architecture  views,  requirements  hierarchies,  diagrams,  and 
simulation  of  system  operations.  M&S  allows  for  systems  to  be  tested  prior  to 
implementation  to  discover  gaps,  deficiencies,  or  to  display  the  extent  of  certain 
capabilities.  M&S  reduces  cost  and  time  in  the  latter  stages  of  system  test  and 
deployment  (Bailey  2013). 

There  were  two  key  steps  in  the  team’s  M&S  process.  The  first  consisted  of 
modeling  the  requirements,  functions,  and  DODAF  views  using  Vitech’s  CORE 
software.  The  second  step  was  two-fold:  the  first  part  consisted  of  simulating  the  SCMM 
system  output;  the  second  part  consisted  of  simulating  the  current  manual  process  to 
calculate  which  spare  parts  to  allocate  to  the  various  support  locations.  The  first 
simulation  utilized  Microsoft  Excel,  which  simulated  the  generation  of  a  sample  report, 
and  gave  the  team  a  visual  tool  to  begin  understanding  the  inputs  and  outputs  of  the 
system.  The  second  simulation  utilized  ExtendSim  to  simulate  the  movement  of  data 
across  various  processes  in  the  current  “manual”  method  in  comparison  with  the 
“automated”  method  that  the  system  will  provide. 

A.  SYSTEM  MODELING 

The  system’s  architecture,  functions,  requirements,  and  various  DODAE  views 
were  modeled  in  Vitech’s  CORE.  CORE  is  a  robust  systems  engineering  and  project 
management  tool  that  allows  the  user  to  quickly  house  and  document  important  data 
pertinent  to  systems  engineering  problems  (Vitech  2013).  CORE  is  especially  useful  for 
requirements  management,  behavior  analysis,  architecture  development,  and  validation 
and  verification  (Vitech  2013).  It  was  used  not  only  as  a  tool  but  to  also 
understand/control  the  design  and  mitigate  project  risk.  This  was  done  by  linking  the 
individual  elements  in  CORE  to  a  central  model.  These  linkages  reduced  redundancy  and 
error  by  creating  traceability  and  accountability.  Ultimately,  CORE  was  used  to  increase 
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system  design  performance,  evaluate  data,  and  create  DODAF  products  (Vitech  2013). 
DODAF  products  provide  a  standardized  set  of  diagrams  or  views  that  allow  the  system 
designers  to  show  or  “model”  key  attributes  of  the  system. 

CORE  enabled  the  team  to  use  a  model  based  systems  engineering  (MBSE) 
approach.  MBSE  is  known  to  be  a  simplified,  layered  system  design  approach,  which 
allowed  the  team  to  focus  on  engineering  rather  than  the  tool.  CORE’S  internal  tool 
known  as  a  “parser”  allowed  data  to  be  entered  into  any  location  within  CORE  and  have 
attributes  assigned  to  them.  This  data  would  then  be  distributed  or  “parsed”  into 
appropriate  diagrams,  categories,  and  tables,  effectively  updating  all  model  data 
immediately.  Visualization  of  requirements  interaction  was  simplified  with  flexible 
model  construction.  This  allowed  for  a  variety  of  graphical  views  such  as:  hierarchies, 
physical  block,  N-squared  (N  ),  EEBDs,  and  integrated  definition  for  function  modeling 
(IDEEO).  Automated  documentation  also  helped  create  some  DODAE  views  instantly 
from  the  system  definition  database  (Vitech  2013).  CORE  also  allowed  the  team  to: 

•  capture  the  customer  needs  accurately  through  requirements  management 
(Vitech  2013). 

•  identify  system  functionality  (Vitech  2013). 

•  document  and  build  system  architecture  through  subsystems  and 
components  (Vitech  2013). 

•  create  system  design  traceability  (Vitech  2013). 

•  provide  system  documentation  (Vitech  2013). 

As  discussed  in  in  the  System  Requirements  chapter,  once  a  baseline  was  created, 
CORE  allowed  the  team  to  maintain  architecture  validity  throughout  refinement  and 
discussions  with  the  sponsor.  The  baseline  is  the  initial  set  of  data  that  the  team 
developed  to  model  the  system.  This  data  included  the  initial  functions,  requirements,  and 
views  based  on  early  discussion  with  the  sponsor.  Modeling  a  baseline  of  the  system  was 
important  because  it  provided  a  detailed  view  of  the  system,  which  was  used  for  future 
meetings  with  the  sponsor  to  elicit  feedback.  All  models  in  CORE  are  built  around  and 
linked  to  a  central  repository  (Vitech  2013).  This  allowed  for  a  change  that  was  made  in 
one  diagram  to  be  reflected  across  all  diagrams  (Vitech  2013).  These  diagrams  were  not 
only  useful  in  creating  DODAE  deliverables,  but  also  they  were  used  to  effectively 
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communicate  the  architecture  to  the  team  and  sponsor.  Deliverables  included  FFBDs, 
HBDs,  use  case,  and  the  functional  requirements  table  found  in  the  Needs  Analysis 
chapter;  an  input,  control/constraint,  output,  and  mechanism  (ICOM)  diagram,  context 
diagram,  and  system  requirements  table  found  in  the  System  Requirements  chapter;  and 
architecture  views  found  in  the  System  Architecture  chapter. 

B.  SYSTEM  SIMULATION 

The  system  was  simulated  in  two  ways.  The  team  decided  it  would  be  useful  to 
simulate  a  sample  report  generation  as  a  proof  of  principle,  discussed  below,  and  to  also 
simulate  system  processes.  The  report  simulation  was  done  through  Microsoft  Excel  and 
the  systems  processes  were  simulated  through  ExtendSim. 

I.  Microsoft  Excel  Simulation 

The  Excel  simulation  was  a  proof  of  principle  that  emulated  the  input  data, 
processing,  and  output  report  that  was  expected  of  the  system.  Microsoft  Excel  was 
chosen  because  it  is  readily  available  throughout  the  Navy;  it  is  a  commonly  used  and 
accepted  form  of  data  storage  and  processing,  and  has  a  multitude  of  accepted  file 
formats.  As  stated  on  the  Microsoft  Office  website: 

Excel  is  a  spreadsheet  program  in  the  Microsoft  Office  system.  You  can 
use  Excel  to  create  and  format  workbooks  (a  collection  of  spreadsheets)  in 
order  to  analyze  data  and  make  more  informed  business  decisions. 
Specifically,  you  can  use  Excel  to  track  data,  build  models  for  analyzing 
data,  write  formulas  to  perform  calculations  on  that  data,  pivot  the  data  in 
numerous  ways,  and  present  data  in  a  variety  of  professional  looking 
charts.  Common  scenarios  for  using  Excel  include: 

•  Reporting  You  can  create  various  types  of  reports  in  Excel  that 
reflect  your  data  analysis  or  summarize  your  data — for  example, 
reports  that  measure  project  performance,  show  variance  between 
projected  and  actual  results,  or  reports  that  you  can  use  to  forecast 
data. 

•  Tracking  You  can  use  Excel  to  keep  track  of  data  in  a  time  sheet  or 
list — for  example,  a  time  sheet  for  tracking  work,  or  an  inventory 
list  that  keeps  track  of  equipment.  (Microsoft  2013) 
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The  approach  was  to  begin  with  a  simple  simulation  and  then  increase  the 
complexity  of  the  simulation  as  time  permitted.  The  final  product  goal  was  to  account  for 
all  inputs  from  various  databases  that  would  connect  to  the  system.  For  the  proof  of 
principle  and  to  begin  the  process  the  agreed  upon  user  inputs  were  ship,  mission, 
location,  and  mission  duration.  Database  inputs  of  concern  were  failure  rate  (or  an 
equivalent  such  as  MTBF)  and  criticality  of  the  part.  The  initial  algorithm  concept  is 
detailed  in  the  following  process: 

User  sets  the  inputs  of  ship,  mission  type,  location,  and  duration.  Then  the 
database  inputs  that  relate  to  user  inputs  would  be  populated  into  a  spreadsheet.  The 
spreadsheet  of  necessary  data  is  then  sorted  by  highest  criticality  and  lowest  MTBF.  And 
finally,  the  spreadsheet  is  ready  for  viewing  by  the  user.  In  order  to  begin  the  Excel 
simulation  six  tabs  were  initially  created: 

•  User  input:  This  simulated  the  users  selecting/entering  their  inputs 

•  Output  report:  This  is  where  the  report  was  generated  per  the  user’s  inputs 

•  CDMD-OA:  This  simulated  database  inputs  from  CDMD-OA 

•  AMPS:  This  simulated  database  inputs  from  AMPS 

•  Total  input  database  data:  This  simulated  where  the  total  Database  inputs 
would  be  aggregated 

•  Miscellaneous  data:  This  stored  all  internal  data  to  the  simulation 

The  user  inputs  were  limited  to  ship,  mission  location,  and  mission  duration.  In 
order  to  limit  the  inputs  of  the  user  dropdown  boxes  were  created  for  each  input,  as 
shown  in  Figure  57. 
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Figure  57.  Drop-Down  Input  Boxes 


Figure  58  displays  the  contents  of  the  dropdown  boxes,  which  are  contained  in  the 
“Misc.  Data”  tab.  Each  user  input  had  a  given  selection  of  options.  The  “Ship”  input  was 
given  a  selection  of  “LCS  1,”  “LCS  2,”  and  “LCS  3.”  The  “Mission”  input  was  given  a 
selection  of  “Mine  Sweeping,”  “AAW,”  and  “SUW.”  The  “Location”  input  was  given  a 
selection  of  “Pacific,”  “Atlantic,”  “Indian,”  and  “Arctic.”  The  “Mission  Duration”  input 
was  left  as  an  open  field  for  the  user  to  enter  a  length  of  time  in  days. 
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Figure  58.  Misc.  Data  Tab 


Drop  down  boxes  were  created  in  Excel  by  going  to  Data>Data  Validation>,  as 
shown  in  Figure  59. 


Figure  59.  Data  Validation  Application 
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The  data  validation  window  Figure  60  used  the  following  selections  of  “Allow” 


and  “Source.” 


Figure  60.  Data  Validation  Window 

The  CDMD-OA  and  AMPS  tabs  were  populated  with  “Part  Name,”  “Part 
Number,”  “Failure  Rate  (MTBF),”  “Criticality,”  “Numerical  Criticality,”  “Dimensions 
(weight),”  “Cost,”  “Config  (mission),”  and  “Config  (Ship).”  The  CDMD-OA  tab 
received  generic  part  names  of  “Test  1”  through  “Test  20”  and  generic  part  numbers  of 
“1”  through  “20.”  See  Figure  61. 
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Figure  6 1 .  CDMD-OA  Tab 


The  AMPS  tab  received  generic  part  names  of  “Test  21”  through  “Test  40”  and 
generic  part  numbers  of  “21”  through  “40.”  Both  the  CDMD-OA  and  AMPS  tabs 
received  the  following  randomized  Excel  values  for  testing: 

•  “Failure  rate  (MTBF)”  =RANDBETWEEN(1000,  5000) 

•  “Criticality”  received  “low,”  “med,”  “high,”  or  “very  high”  starting  with 
“low”  and  repeating  in  that  order  until  all  parts  received  a  value. 

•  “Numerical  Criticality”  was  a  numerical  equivalent  of  the  descriptive 
value  given  in  the  “Criticality”  fields  =IF(D2=“low,”  1,  IF(D2=“med,”  2, 
IF(D2=“high,”  3,  IF(D2=“very  high,”  4,  0)))) 

•  low  =  1 

•  med  =  2 

•  high  =  3 

•  very  high  =  4 

•  “Dimensions  (weight)”  =RANDBETWEEN(1,  10000) 
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•  “Cost”  =RANDBETWEEN(  10000,  10000000) 

•  “Config  (mission)”  received  “Mine  Sweeping,”  “SUW,”  or  “AAW” 
starting  with  “Mine  Sweeping”  and  repeating  in  that  order  until  all  parts 
received  a  value. 

•  “Config  (ship)”  received  “ECS  1,”  “ECS  2,”  or  “ECS  3”  starting  with 
“ECS  1”  and  repeating  in  that  order  until  all  parts  received  a  value. 

The  next  step  was  to  have  Excel  consolidate  the  data  that  was  now  coming  from 
two  databases.  Once  the  data  was  consolidated  the  Excel  file  would  automatically  apply 
the  sort  and  rank  with  highest  criticality  and  lowest  MTBE.  However,  this  would  still 
include  all  the  data,  even  the  data  that  was  not  applicable  to  the  user’s  inputs.  In  order  to 
delete  the  data  that  was  not  applicable  to  the  user’s  needs,  the  example  code  of 
“=IE(‘User  Input’ !$A$l=‘Total  Database’ !$I$2,IE(‘User  Input’ !$A$2=‘Total 
Database’ !$H$2, ’Total  Database’ !B2,0),0)  was  used  to  create  a  line  of  “0”‘s  in  the  non- 
applicable  lines  of  data.  The  “0”  lines  were  deleted  and  the  resulting  data  was  placed  in 
the  “Output  Report”  tab.  This  was  accomplished  with  a  macro  that  can  be  found  in  the 
appendix  titled  Modeling  and  Simulation  Macro. 

Einally,  once  the  data  was  displayed  in  the  “Output  Report”  tab,  it  was 
conditionally  formatted  based  on  the  weight  constraint  set  by  the  ship  selection.  The 
output  report  has  already  been  ranked  by  order  of  importance,  and  now  the  determination 
of  which  parts  are  to  go  on  ship  and  which  parts  are  to  go  to  a  warehouse  must  be 
determined.  Starting  at  the  top  and  working  its  way  down,  the  conditional  formatting 
highlighted  the  parts  that  add  up  to  but  below  the  set  ship’s  weight  constraint.  The  rest  of 
the  parts  were  highlighted  in  a  different  color  designating  them  for  the  warehouse. 

The  proof  of  principle  simulation  of  the  report  generation  worked  as  intended  and 
produced  the  outputs  expected.  Based  on  the  input  data  provided  by  the  sponsor  and 
initial  processes  being  simulated,  the  output  report  was  populated  correctly.  The  outputs 
were  also  displayed  in  a  readable  format  that  the  team  could  use  and  present  to  the 
sponsor.  It  provided  a  starting  point  that  with  further  research  and  technical  expertise 
could  be  developed  further  to  conduct  more  complicated  analysis.  It  can  be  concluded 
that  a  SCMM  system  could  develop  the  necessary  outputs  and  export  the  data  into  a 
useable  report. 
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2. 


ExtendSim  Simulation 


The  second  simulation  was  with  ExtendSim,  which  allowed  for  a  comparison  of 
the  baseline  “manual”  method  to  the  system’s  “automated”  method.  ExtendSim  was 
selected  because  of  its  capability  to  accurately  represent  the  process  and  that  it  was 
offered  for  use  by  NFS’s  Voyager  Remote  Application.  Other  simulation  software  was 
considered,  such  as  MATEAB,  but  due  to  its  cost  and  Navy  restrictions  for  installation, 
the  team  decided  to  move  forward  with  ExtendSim. 

ExtendSim  is  a  powerful,  leading  edge  simulation  tool.  Using  ExtendSim, 
you  can  develop  dynamic  models  of  existing  or  proposed  processes  in  a 
wide  variety  of  fields.  Use  ExtendSim  to  create  models  from  building 
blocks,  explore  the  processes  involved,  and  see  how  they  relate.  Then 
change  assumptions  to  arrive  at  an  optimum  solution.  ExtendSim  and  your 
imagination  are  all  you  need  to  create  professional  models  that  meet  your 
business,  industrial,  and  academic  needs. 

ExtendSim  is  an  easy-to-use,  yet  extremely  powerful,  tool  for  simulating 
processes.  It  helps  you  understand  complex  systems  and  produce  better 
results  faster.  According  to  the  “ExtendSim  Overview”  webpage,  with 
ExtendSim  you  can: 

•  Predict  the  course  and  results  of  certain  actions 

•  Gain  insight  and  stimulate  creative  thinking 

•  Visualize  your  processes  logically  or  in  a  virtual  environment 

•  Identify  problem  areas  before  implementation 

•  Explore  the  potential  effects  of  modifications 

•  Optimize  your  operations 

•  Evaluate  ideas  and  identify  inefficiencies 

•  Understand  why  observed  events  occur 

•  Communicate  the  integrity  and  feasibility  of  your  plans. 

(ImagineThat!  2013) 

The  “manual”  method  simulation  essentially  depicts  what  a  standard  user  did 
before  the  SCMM  system  was  created.  This  included  logging  into  various  databases, 
entering  input  data  for  each  database,  retrieving  relevant  data  (either  by  saving,  or  copy 
and  paste),  and  then  assembling  it  into  Excel  and  analyzing  it  to  obtain  a  sparing  list 
based  on  high  failure  rates  of  parts.  The  “automated”  method  simulation  of  the  SCMM 
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system  eliminates  the  time  required  for  multiple  logins  and  extracts  the  data  directly  from 
the  database.  It  also  eliminates  the  assemblage  into  Excel  and  the  processing  that  was 
normally  done.  Clearly,  the  SCMM  system  is  more  efficient. 


The  model  in  ExtendSim  was  built  using  a  discrete  event  model  because  the 
system  needed  to  have  a  time-dependent  flow  that  depicted  a  process  of  operations.  Eirst 
the  simulation  parameters  of  End  time  (24)  and  Global  time  units  (minutes)  were  set  in 
the  Simulation  Setup  tab.  Next  the  Item  Eibrary  was  opened  and  an  Executive  block, 
Eigure  62,  was  placed  into  the  simulation.  An  executive  block  is  a  requirement  for  all 
discrete  event  modeling. 


Eigure  62.  Executive  Block 


Next  is  to  start  the  data  flow  by  creating  the  “report.”  This  was  done  with  the 
Routing:  Create  block  Eigure  63,  and  was  set  to  generate  a  report  every  hour. 


Start  Report 


Eigure  63.  Routing:  Create  Block 


After  the  report  has  started  it  receives  user  input  data  or  applicability  data.  The 
first  is  ship  input  and  the  time  it  takes  to  accomplish  this  is  set  to  one  minute  in  the 
Activity  block  Eigure  64. 
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Figure  64.  Activity  Block 

After  the  input  has  been  noted,  an  attribute  is  assigned  (i.e.,  LCS  1)  through  the 
Attributes  block  Figure  65. 


Figure  65.  Attributes  Block 

This  is  tied  to  a  random  variable  block  Figure  66  that  is  set  to  randomly 
(probability  of  50  percent)  assign  it  either  LCS  1  or  LCS  2. 


Figure  66.  Random  Variable  Block 

This  was  again  all  repeated  for  the  second  user  input  of  mission.  Figure  67  shows 
both  sets  of  blocks  designating  the  two  inputs. 
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Figure  67.  User  Ship  and  Mission  Inputs 


This  initial  part  of  the  simulation  is  the  same  for  both  the  “automated”  and 
“manual”  methods.  The  only  differenee  now  is  that  they  proeeed  through  different 
follow-on  activities  as  shown  in  Figure  68. 


Flit  Edit  Ttxt  Libraiy  Model  Oitabaie  Develop  Run  Window  Help 

D  ig  Biar*  ♦  cdH  »  .If  ^  t  ii ■  <1  €  I  Bl 


Figure  68.  ExtendSim  Simulation  Overview 
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The  automated  process  exits  the  user  inputs  and  travels  to  a  single  database 
activity  block,  whereas  the  manual  process  requires  each  database  to  be  accessed 
individually  with  two  separate  blocks.  The  automated  process  also  then  hits  a  singular 
Excel  Sort  activity  block,  and  again,  the  manual  process  hits  a  multitude  of  Excel  process 
activity  blocks.  Both  processes  feed  into  a  Routing:  Exit  block,  Eigure  69.  The  exit  block 
signifies  the  end  of  the  route  that  the  report  takes. 


Spares  Report 

Eigure  69.  Exit  Block 


The  Exit  block  then  feeds  into  a  Plotter,  Discrete  Event  block,  Eigure  70,  that  then 
populates  and  displays  a  graph  called  a  simulation  plot,  Eigure  71,  at  the  end  of  the 
simulation. 


152 


Figure  7 1 .  Simulation  Plot 


The  plot  and  simulation  results  confirmed  the  hypothesis  that  the  manual  method 
is  less  productive  in  comparison  to  the  automated  method.  This  result  gave  the  team  a 
great  base  for  future  simulations. 

The  system  process  simulation  worked  as  intended  and  produced  the  outputs 
expected.  The  goal  was  to  demonstrate  how  time  consuming  the  “manual”  method  was  in 
comparison  to  the  “automated  method.”  The  team  expected  the  “automated”  method  to 
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be  faster,  but  was  surprised  at  how  long  it  took  items  to  progress  through  the  “manual” 
queue.  Therefore,  the  team  concluded  that  a  SCMM  system  would  improve  supply  chain 
management  performance. 

C.  SUMMARY 

The  modeling  and  simulation  phase  of  the  tailored  SE  vee  process  consisted  of 
modeling  the  requirements,  hierarchies,  diagrams,  and  creating  system  architecture  views 
in  CORE;  while  simulating  the  conceptual  design  of  the  SCMM  system  was  developed 
using  Excel  and  ExtendSim.  Information  captured  in  CORE  allowed  for  the  effective 
documentation  of  system  requirements,  design  baselines,  and  report  generation  during  the 
development  of  the  project.  The  use  of  modeling  software  tools  enabled  the  RSRP  team 
to  create  DODAE  architectures  with  software  inherent  linkages  for  traceability 
throughout  the  development  of  the  system  requirements,  which  was  then  illustrated  by 
creating  system  architecture  views. 

The  MBSE  approach  used  by  team  RSRP  focused  on  creation  of  the  system 
elements  and  interfaces  using  the  CORE  software  for  a  layered  design.  CORE  allowed 
the  team  to  make  modifications  and  iterations  throughout  the  development  of  the  system 
that  did  not  compromise  the  integrity  or  cohesion  of  the  modeling  process.  CORE  allows 
system  components  to  retain  or  modify  relationships  depending  on  the  developer  inputs. 
The  iterative  development  of  system  requirements  was  simplified  by  the  ability  of  CORE 
to  show  requirement  relationships  and  the  visualization  of  the  interfaces  and  boundaries 
of  the  system’s  elements. 

The  simulation  of  the  system  was  accomplished  by  using  Microsoft  Excel  to 
emulate  input  data  being  processed  to  create  a  final  output  report  and  ExtendSim  to 
simulate  the  system  processes  in  detail.  The  simulations  were  created  with  a  similar 
iterative  process  as  the  modeling  approach:  beginning  with  simple  inputs  and  processes, 
observing  the  process  interactions  and  outputs,  and  then  increasing  the  complexity  of  the 
simulations  by  adding  additional  detailed  inputs,  interfaces,  criticality  margins,  and  ship 
and  part  configurations  with  the  inclusion  of  a  time  element  for  system  optimization.  The 
simulation  results  confirmed  that  with  sponsor  identified  and  team  developed  inputs  an 
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output  report  could  be  generated  and  an  “automated  method”  surpassed  the  performance 
of  a  “manual  method”  with  the  team  concluding  that  an  SCMM  system  would  improve 
modular  and  flexible  design  ship  supply  chain  management  performance. 
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VII.  SYSTEM  INTEGRATION  AND  TEST,  COMPONENT 
VERIFICATION,  SYSTEM  ANALYSIS,  AND  VALIDATION 

The  right  side  of  team  RSRP’s  tailored  vee  includes  several  SE  phases  that  ensure 
the  development  of  the  system  meets  customer  defined  requirements  and  that  the  SCMM 
can  be  a  functional  system  once  it  is  fielded.  These  include  the  system  integration  and 
test,  component  verification,  system  analysis,  and  system  validation  phases.  These  phases 
are  critical  to  the  maturity  of  the  system  design  with  each  step  providing  valuable 
feedback  towards  an  earlier  phase  of  the  SE  vee.  An  integrated  test  approach  was  the 
basic  construct  to  test,  evaluate,  and  facilitate  the  necessary  verification  and  validation  of 
the  overall  system  utilizing  the  simulated  system  design  solution  that  was  developed 
during  the  M&S  phase.  Due  to  time  constraints  the  verification  and  validation  phases 
were  limited  to  the  test  and  analysis  of  the  developed  SCMM  simulation  instead  of  a 
physical  prototype.  System  analysis  was  performed  concurrently  with  the  conceptual 
design  phase  using  an  AoA  methodology.  Cost  and  risk  analyses  were  conducted  on  the 
output  of  the  AoA  using  COSYSMO  and  a  risk  management  process. 

A.  SYSTEM  INTEGRATION  AND  TEST 

The  system  integration  and  test  phase  entailed  the  verification,  system  analysis, 
and  system  validation  of  the  simulated  design  solution  that  was  developed  in  Excel 
during  the  M&S  phase.  The  Excel  simulation  was  a  proof  of  principle  that  emulated  the 
input  data,  processing,  and  output  report  that  was  expected  of  the  system.  The  initially 
defined  requirements  were  reviewed  and  evaluated  to  determine  the  level  of  testing 
necessary  to  verify  and  test  the  SCMM  system  simulation.  These  initial  requirements  are 
listed  in  the  Measures  and  Metrics  table  found  in  the  Additional  and  Expanded  Test 
Documentation  appendix.  The  initial  requirements  can  be  found  in  the  “Requirements” 
column  of  that  table.  Note  that  these  are  the  initial  requirements,  and  do  not  match  the 
current  requirement  structure  that  is  detailed  in  the  System  Requirements  chapter. 
Working  with  the  sponsor,  some  of  the  requirements  were  changed  and/or  better  defined 
during  the  course  of  the  project.  The  initial  requirements,  available  when  the  simulation 

was  being  constructed,  were  used  as  the  testing  criteria  to  ensure  the  system’s 
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effectiveness  and  suitability.  The  system  integration  and  test  phase  was  accomplished 
concurrently  with  the  modeling  and  simulation  phase  to  ensure  readiness  and  maturity  of 
the  system  conceptual  design  within  the  project  schedule. 

1.  Strategy 

A  testing  strategy  that  defined  the  testing  levels,  ensured  proper  configuration 
management,  described  the  use  of  appropriate  tools,  and  used  measure  and  metrics  to 
ensure  the  requirements  were  met  was  followed. 

a.  Testing  Levels 

Testing  occurred  in  three  levels  over  several  phases.  The  first  level  was  testing  the 
user  interface.  The  user  interface  was  tested  to  show  that  the  user  has  the  ability  to  input 
commands  and  receive  outputs  from  the  system.  This  level  of  testing  was  done  early  and 
often  during  the  development  of  the  Excel  model  of  the  SCMM  system. 

The  second  level  of  testing  consisted  of  testing  the  requirements  as  defined  in  the 
System  Requirements  chapter.  An  approach  for  testing  the  high-level  requirements  was 
developed  that  entailed  testing  the  requirements  against  specific  test  criteria.  This  level  of 
testing  was  conducted  towards  the  end  of  the  development  of  the  Excel  model  of  the 
SCMM  system. 

The  third  level  of  testing  consists  of  testing  the  internal  algorithms  of  the  Excel 
based  system  model.  The  third  level  of  testing  was  not  conducted  due  to  the  time 
constraints  of  the  capstone  project.  This  level  of  testing  is  intended  to  verify  that  the 
internal  algorithms  of  the  model  function  as  expected.  Scenarios  should  be  run  with 
specific  inputs  that  would  generate  expected  outputs  to  verify  that  the  inputs  match  the 
expected  outputs. 

b.  Configuration  Management  and  Change  Control 

Prior  to  testing,  the  system  model  was  assigned  the  appropriate  change  control  / 
revision  number.  After  that  point,  any  changes  to  the  SCMM  Excel  simulation 
spreadsheet  or  SCMM  ExtendSim  simulation  spreadsheet  would  require  a  notification  of 
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changes  and  a  new  revision  number.  Changes  were  not  made  during  testing  without  prior 
notification  and  appropriate  change  control.  The  spreadsheets  used  for  configuration 
management  and  change  control  can  be  viewed  in  the  Configuration  Management  and 
Change  Control  section  of  the  Additional  and  Expanded  Test  Documentation  appendix. 

c.  Test  Tools 

Several  tools  were  used  during  the  test  and  verification  of  the  model.  They  are 
explained  in  the  following  paragraphs. 

1.  MS  Excel 

Excel  was  used  to  run  the  Excel  model.  It  was  also  used  to  develop  and  build  the 
test  data  and  scenarios  used  to  test  the  Excel  model. 

2.  ExtendSim 

ExtendSim  was  used  to  run  the  ExtendSim  simulation  of  the  model.  It  was  also 
used  to  develop  and  build  the  test  data  and  scenarios  used  to  test  the  ExtendSim 
simulation  of  the  model. 

3.  Hardware 

The  hardware  used  to  run  and  test  the  ExtendSim  simulation  and  Excel  model  was 
dependent  on  the  individual  testers  and  the  available  hardware.  Any  hardware  able  to  run 
ExtendSim  or  Excel  was  able  to  run  and  test  the  corresponding  simulation  or  model. 

d.  Measures  and  Metrics 

The  defined  functional  and  nonfunctional  requirements  were  tested.  Each  of  the 
identified  requirements  was  determined  to  be  testable  or  not  testable,  and  then  was 
incorporated  into  a  testing  schema.  This  became  the  test  plan  and  includes  the  test 
approach  used  for  each  requirement.  The  test  measures  and  metrics  in  the  form  of  a  table 
can  be  viewed  in  the  Test  Measures  and  Metrics  section  of  the  Additional  and  Expanded 
Test  Documentation  appendix. 
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The  results  of  the  testing  were  collected  in  a  test  results  report.  This  test  report 
provided  feedback  to  the  SCMM  capstone  team  on  whether  the  system  met  the 
requirements  as  defined.  This  feedback  included: 

•  Test  Pass/Fail  status:  Status  of  all  the  measures  and  metrics  and  whether 
the  tests  for  such  passed  or  failed  were  recorded. 

•  Errors  or  defects:  All  errors  or  defects  found  during  the  testing  were 
identified  and  recorded. 

•  Diversions  from  the  test  scenarios:  Any  additional  diversions  or  issues 
discovered  were  recorded  as  part  of  the  testing  report  and  summary. 

Item  pass/fail  criteria  was  based  on  test  scenarios  and  documented  as  required. 
Suspension  would  only  occur  if  the  SCMM  system  simulation  was  not  ready  for  testing. 
Testing  would  resume  upon  the  availability  of  the  simulation  of  the  SCMM  system.  The 
simulation  was  available  for  testing  at  all  times  during  the  test  period.  The  test  results 
report  can  be  found  in  the  Test  Results  Report  section  of  the  Additional  and  Expanded 
Test  Documentation  appendix. 

2.  Testing  Risks 

Not  all  aspects  of  the  project  were  within  control  of  the  test  team.  There  were 
several  issues  that  had  potential  risk  impact  on  the  testing  of  the  SCMM  system.  The  risk 
issues  were  documented  below  and  the  risk  had  been  accepted. 

•  External  systems  data  formatting  specifications:  Assumptions  had  been 
made  based  on  what  data  and  data  formatting  external  systems,  such  as 
NAVSUP,  ERP,  or  CDMD-OA,  would  be  providing  to  the  SCMM 
system.  These  external  systems  are  third  party  products  in  which  the  data 
formatting  specifications  are  not  known  to  the  test  team.  This  information 
had  been  assumed  based  on  the  SCMM  System  Development  Plan  for 
testing  purposes. 

•  External  systems  interface  specifications:  Assumptions  had  been  made 
based  on  what  the  interface  specifications  are  for  the  external  systems, 
such  as  NAVSUP,  ERP,  or  CDMD-OA,  that  will  be  interfacing  with  the 
SCMM  system.  These  external  systems  are  third  party  products  in  which 
the  interface  specifications  are  not  known  to  the  test  team.  This 
information  has  been  assumed  based  on  the  SCMM  System  Development 
Plan  for  testing  purposes. 


160 


•  Development  constraints:  Due  to  possible  development  issues  and 
constraints,  the  SCMM  system  development  may  not  meet  the  planned 
schedule,  delaying  and  possibly  halting  the  testing. 

3.  Features  To  Be  Tested  /  Not  To  Be  Tested 

The  following  is  a  list  of  the  areas  tested  during  testing  of  the  application. 

•  User  interface:  User  interface  was  tested  to  show  that  the  user  has  the 
ability  to  input  commands  and  receive  outputs  from  the  system.  Most  of 
the  defined  user  interface  requirements  are  listed  as  requirements  1.1  and 
1.2  in  the  Measurements  and  Metrics  table. 

•  High-Level  Requirements:  A  list  of  the  high-level  requirements  recorded 
in  the  Measurements  and  Metrics  table  shows  the  high-level  requirements 
that  were  tested,  along  with  the  approach  for  testing. 

The  following  is  a  list  of  areas  not  specifically  addressed  or  tested.  Testing  of 
these  features  may  occur  at  a  later  date. 

•  Internal  algorithms:  In  addition  to  testing  the  user  interface  and  high-level 
requirements,  the  system  will  be  tested  to  verify  that  the  internal 
algorithms  function  as  expected.  Scenarios  will  be  run  with  specific  input 
and  expected  output  against  the  system  to  verify  the  output  matches  the 
expected  outputs. 

•  Lower-level  requirements:  Lower-level  functional  and  nonfunctional 
requirements  have  not  been  fully  identified.  Testing  will  only  apply  to  the 
requirements  that  have  been  identified.  The  risk  for  not  testing  is  medium. 
Most  of  the  high-level  requirements  will  be  covered  to  verify  system 
functionality  limiting  the  impact. 

•  Interface  and  integration:  The  interface  specifications  have  not  been 
identified  for  the  external  systems;  therefore,  the  features  will  not  be 
tested.  The  risk  for  not  testing  is  high.  Without  testing,  the  verification  and 
acceptance  of  the  interface  with  external  systems  cannot  occur. 

4.  Testing  Summary 

The  test  results  report  captures  the  results  of  the  testing  performed  on  the  Excel 
simulation  of  the  SCMM  system.  Most  of  the  requirements  were  met  with  the  exception 
of  those  detailed  below: 

•  Data  can  be  inputted  via  the  tables  in  the  program,  which  simulates 
collected  data  from  sources,  versus  being  able  to  be  inputted  by  the  user. 
Requirements  do  not  specify. 
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•  Current  model  does  not  take  into  consideration  other  facilities,  such  as  the 
mission  package  support  facility  (MPSF)  or  OCONUS  warehouses. 

•  Unable  to  verify  the  following  until  requirements  are  further  defined  (xxx 
denotes  an  unknown  time  specified  in  seconds): 

•  Verify  the  program  provides  Verify  the  program  provides  a  report 
out  of  the  output  data  within  xxx  seconds. 

•  Verify  the  program  able  to  handle  xxx  simultaneous  users. 

•  Verify  the  program  able  to  handle  xxx  transactions  per  minute. 

•  Able  to  save  Excel  file,  but  not  the  output  report  to  a  separate  Excel  file. 
Complete  details  can  be  found  in  the  Test  Report  Results  section  in  the  Additional  and 
Expanded  Test  Documentation  appendix. 

B.  VERIFICATION  AND  VALIDATION 

The  purpose  of  the  verification  and  validation  phases  is  to  demonstrate  the 
system’s  effectiveness  as  a  whole.  Prior  to  the  initial  system  demonstration,  each 
component  should  be  inspected  and  verified  to  determine  if  it  has  met  the  requirements. 
An  analysis  of  the  system  is  performed  to  examine  system  readiness.  Easily,  the  system 
should  be  validated  for  effectiveness  and  suitability.  Due  to  time  constraints,  the  team 
conducted  various  portions  of  these  phases  but  was  unable  to  validate  a  prototype  system 
for  initial  demonstration  due  to  the  time  constraints  of  the  capstone  project’s  timeframe. 

I.  Component  Verification 

The  SCMM  system  is  a  software  intensive  system  with  the  expected  components 
to  include  software  code,  database  software,  algorithm(s),  software  interfaces,  and 
external  database  interfaces.  A  user’s  host  platform  will  be  needed  to  check  for 
interoperability  with  the  SCMM  system.  Component  verification  should  be  performed 
through  an  effective  combination  of  analysis,  inspection,  demonstration,  and  testing 
through  bench  test  models  of  the  physical/software  design.  The  verification  process 
gauges  the  maturity  of  each  component  prior  to  integrating  the  overall  system  design 
solution  by  developing  a  detailed  robust  plan  with  a  supporting  comprehensive  data 
collection  process  for  analysis  and  reporting.  The  objective  for  verification  was  to 
accurately  account  for  system  maturity  as  these  components  are  integrated  and  to  gain 
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confidence  that  they  will  perform  as  intended.  Developing  a  prototype  of  the  system  for 
component  verification  purposes  was  beyond  the  scope  of  the  project  due  to  time 
constraints. 

2.  System  Analysis 

System  analysis  comprised  multiple  analyses  conducted  throughout  the  design  of 
the  SCMM  system.  System  analysis  was  performed  during  the  conceptual  design  phase 
when  design  alternatives  were  evaluated  by  conducting  an  AoA  to  identify  potential 
models  that  could  be  adapted  to  satisfy  the  SCMM  system’s  requirements.  The  AoA  was 
conducted  using  value  modeling,  based  on  a  weighted  chart,  and  with  a  numerical 
evaluation  matrix  to  determine  the  model  that  best  satisfied  the  stakeholders’ 
requirements  (Buede  2000).  Cost  analysis  was  also  conducted  during  this  phase  to 
evaluate  the  different  model  alternatives.  The  team  used  COSYSMO  to  help  assess  the 
cost  and  schedule  implications  of  systems  engineering  decisions.  Risk  analysis  was 
conducted  throughout  the  SEP  focusing  on  the  SCMM  system  and  capstone  project  risks. 
This  analysis  resulted  in  the  development  of  the  Risk  Management  Plan  addressing  the 
programmatic  and  technical  risks  of  the  project  and  system. 

The  end  goal  of  system  analysis  is  to  evaluate  the  integrated  system’s 
performance  and  characteristics  for  qualification  of  the  stakeholders’  requirements.  The 
analysis  of  the  system  is  conducted  to  examine  the  performance  of  the  system  and 
performance  test  results,  environment  and  stress  outcomes,  software  coding,  latency, 
security,  maintainability,  compatibility,  and  safety.  Each  area  can  be  qualified  by 
measuring  it  against  the  functional  performance  requirements  but  further  system 
demonstration  needs  to  be  scheduled  to  provide  assurance  that  system  integration  does 
not  disrupt  any  functional  capability  (Buede  2000).  Any  anomalies  should  be  fully 
documented  through  a  formal  report  and  feedback  is  then  provided  to  the  designers  and 
programmers  to  correct  the  discrepancies  in  the  system  design  (Buede  2000).  Due  to  time 
and  resource  constraints,  this  phase  of  the  project  was  scoped  to  include  only  verification, 
system  analysis,  and  system  validation  of  the  simulated  design  solution  versus  a  system 
prototype. 
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3.  System  Validation 

System  validation  ensures  that  the  as-designed  system  meets  the  system 
requirements  in  conformance  with  the  stakeholders’  needs.  The  system  should  be 
validated  by  performing  final  formal  operational  testing  that  determines  effectiveness  and 
suitability  of  the  system.  The  testing  should  provide  insight  on  how  the  system  performs 
under  loaded  operational  conditions  within  a  specified  stressed  environment,  with  live 
users  operating  the  system.  This  system  validation  provides  the  first  time  to  really  assess 
the  true  capability  of  the  system  as  a  whole.  This  process  also  demonstrates  that  the 
designed  system  achieves  its  intended  use  in  the  intended  operational  environment 
(Blanchard  and  Fabrycky  2011).  Although  this  phase  was  not  performed  in  its  entirety 
due  to  the  immaturity  of  the  system  design,  it  is  recommended  that  system  validation 
continue  throughout  the  design  of  the  SCMM  system  by  performing  progressive  and 
iterative  integrated  system  testing  to  validate  the  maturity  of  the  system  and  assess 
overall  system  readiness. 

C.  SUMMARY 

The  right  side  of  team  RSRP’s  tailored  vee  included  several  SE  phases  that 
ensured  the  development  of  the  system  met  customer  defined  requirements  and  the 
SCMM  system  was  functional  once  fielded.  These  phases  included  system  integration 
and  test,  component  verification,  system  analysis,  and  the  system  validation  processes. 
They  were  performed  iteratively  during  this  capstone  project’s  design  of  the  system  to 
refine  requirements  and  to  make  modifications  of  the  system  under  design.  They  should 
continue  to  be  performed  throughout  future  system  design  and  development  efforts  to 
ensure  the  areas  that  were  developed  during  the  left  side  of  the  tailored  vee  were 
completed  to  best  meet  the  stakeholders’  needs. 

During  the  system  integration  and  test  phase  the  simulated  design  solution  was 
subjected  to  verification,  system  analysis,  and  system  validation  processes.  The  initial 
derived  requirements  were  evaluated  to  determine  the  level  of  testing  necessary  to  verify 
the  SCMM  simulation’s  effectiveness  and  suitability.  The  integration  and  test  phase  was 
performed  concurrently  with  the  modeling  and  simulation  phase.  The  integration  and  test 
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strategy  included  defining  appropriate  testing  levels,  establishing  a  configuration 
management  process,  and  identifying  the  necessary  tools  to  evaluate  established 
measures  and  metrics  for  system  requirement  verification  and  validation. 

The  defined  system  integration  and  test  levels  were  partitioned  into  three  areas: 
testing  the  user  interface  to  ensure  the  user  could  efficiently  enter  inputs  and  receive 
appropriate  outputs  from  the  system;  testing  the  defined  requirements  against  specific  test 
criteria;  and  testing  the  internal  algorithms  of  the  Excel  based  system  simulation  to 
ensure  proper  function.  Team  RSRP  was  able  to  complete  the  first  two  levels  of  testing, 
with  the  third  not  being  completed  due  to  time  constraints.  Configuration  management 
during  testing  was  ensured  by  implementing  change  control  of  the  test  events  and 
configurations  of  the  system  under  test  with  assigned  revision  numbers  tracked  and 
documented.  The  tools  used  during  the  test  and  verification  of  the  SCCM  system 
simulation  included  MS  Excel  to  develop  and  build  test  data  and  scenarios,  ExtendSim  to 
test  the  simulated  model’s  functions  and  outputs,  and  necessary  hardware  available  to  the 
testers  to  run  the  test  software.  Measures  and  metrics  were  defined  to  evaluate  the 
functional  and  nonfunctional  requirements  of  the  system.  Results  were  collected  and 
combined  in  to  a  test  results  report  to  document  whether  the  system  under  test  met  the 
requirements  as  defined. 

Due  to  time  constraints  the  verification  and  validation  phases  were  limited  to  the 
test  and  analysis  of  the  developed  SCMM  simulation  instead  of  a  physical  prototype. 
Even  with  these  limitations  the  team  was  able  to  verify  and  validate  portions  of  the 
SCMM  system  under  development  to  ensure  the  stakeholders’  requirements  were  being 
met  in  order  to  address  the  identified  capability  gap. 

During  the  system  analysis  phase,  several  additional  analyses  were  conducted. 
Design  alternatives  were  evaluated  during  the  AoA  conducted  in  the  conceptual  design 
phase;  cost  and  risk  analyses  were  also  performed.  The  AoA  was  conducted  using  value 
modeling,  based  on  a  weighted  chart,  and  with  a  numerical  evaluation  matrix  to 
determine  the  model  that  best  satisfied  the  stakeholders’  requirements.  Cost  analysis  was 
conducted  using  the  constructive  systems  engineering  cost  model  (COSYSMO),  a  model 

used  to  help  assess  the  cost  and  schedule  implications  of  systems  engineering  decisions. 

165 


COSYSMO  was  used  to  evaluate  the  different  alternatives  that  resulted  from  the  AoA. 
The  risk  analysis  focused  on  the  SCMM  system  and  capstone  project  risks.  This  analysis 
was  conducted  throughout  the  SEP  and  resulted  in  the  development  of  the  Risk 
Management  Plan  addressing  the  programmatic  and  technical  risks  of  the  project  and 
system.  The  output  of  the  system  analysis  phase  was  the  identification  of  a  system 
alternative  suitable  for  adaptation  to  support  the  stakeholders’  needs  and  requirements. 
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VIII.  COST  ANALYSIS 


Whereas  the  initial  AoA  evaluation  looked  at  the  comparison  of  requirements  and 
performance  between  alternative  models,  cost  analysis  addresses  the  comparison  of  cost 
between  alternatives,  which  includes  the  significant  cost  drivers  of  schedule  and  manning 
or  effort  that  are  required  to  complete  the  tasking.  Cost  is  treated  as  an  independent 
variable  in  DOD  acquisition  programs.  According  to  Barber  of  the  Defense  Acquisition 
University,  based  on  the  Defense  Acquisition  Guidebook: 

Cost  as  an  independent  variable  (CAIV)  is  basically  an  acquisition  process 
intended  to  integrate  proven  successful  business-related  practices  with 
promising  new  DOD  initiatives  to  obtain  superior,  yet  reasonably  priced, 
warfighting  capabilities.  Traditionally,  the  success  of  acquisition  programs 
has  been  judged  by  their  accomplishments  with  respect  to  three 
parameters:  cost,  schedule  and  performance.  Of  these,  performance 
usually  received  the  most  emphasis,  and,  therefore,  was  treated  as  a 
“fixed”  or  “independent”  variable.  Schedule  and  cost  were  allowed  to  vary 
to  achieve  some  desired  level  of  performance.  In  an  era  of  shrinking 
defense  budgets,  DOD  has  adopted  the  CAIV  philosophy  of  treating  cost 
as  the  independent  variable  of  the  three,  thereby  allowing  performance  and 
schedule  to  vary  somewhat  in  an  attempt  to  keep  weapon  systems 
affordable.  (Barber  2011,  A- 11) 

She  summarizes  CAIV  as  follows: 

CAIV  is  an  acquisition  philosophy  that  emphasizes  keeping  system  life 
cycle  cost  within  an  established  range  by  trading  the  other  system 
acquisition  variables  of  performance  or  schedule.  Since  a  significant 
portion  of  a  system’s  life  cycle  cost  is  fixed  by  its  design,  the  optimum 
time  to  apply  CAIV  principles  is  early  in  the  life  of  an  acquisition 
program.  The  PM  has  authority  to  make  some  changes  within  the  “trade 
space”  between  the  thresholds  and  objectives  documented  in  the  capability 
needs  document  provided  the  change  does  not  result  in  a  KPP  being 
reduced  below  its  threshold  value.  (Barber  2011,  A-13-A-14) 

Cost  analysis  for  the  SCMM  system  was  accomplished  using  the  constructive  systems 
engineering  cost  model  (COSYSMO). 
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A.  CONSTRUCTIVE  SYSTEMS  ENGINEERING  COST  MODEL  AND  COST 

ANALYSIS 

COSYSMO  is  a  model  used  to  help  assess  the  cost  and  schedule  implications  of 
systems  engineering  decisions  (Valerdi  2005).  Based  on  the  initial  AoA  evaluation, 
COSYSMO  was  used  to  compare  the  alternatives  with  the  highest  performance  scores. 
This  comparison  included  OSRAP  and  ME-RBS.  ARROWS  was  not  compared  due  to  its 
previous  integration  into  the  ME-RBS  workstation.  Also  compared  were  the  following 
two  options:  designing  a  completely  new  SCMM  system  (SCMM  [full])  and  designing  a 
“partial”  SCMM  system  (SCMM  [partial]),  which  entails  modification  of  the  existing 
ME-RBS  model  and  makes  it  a  standalone  SCMM  system. 

COSYSMO  uses  multiple  factors  to  determine  cost.  These  factors  include  size 
drivers,  such  as  the  number  of  system  requirements  or  number  of  system  interfaces  that 
define  the  size  of  the  program;  and  cost  drivers,  such  as  understanding  factors  and 
complexity  factors,  which  may  increase  or  decrease  the  cost  depending  on  the  level  of 
difficulty.  Due  to  limited  information  available  on  the  alternatives,  several  of  the  factors 
were  based  on  assumptions. 

Eigure  72  shows  the  inputs  used  for  the  ME-RBS  alternative.  The  full  list  of 
inputs,  input  assumptions,  and  cost  drivers  for  each  alternative  is  in  the  COSYSMO 
Eactors  appendix. 
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COSYSMO  -  Constructive  Systems  Engineering  Model 


Model(s) 

COSYSMO 

Monte  Carlo  Risk  Off  ▼ 

Auto  Calculate  Off  ^ 

Easy 

Nominal  DlfHcult 

#  of  System  Requirements 

55 

30  30 

#  of  System  Interfaces 

3 

#  of  Algorithms 

1 

#  of  Operational  Scenarios 

System  Cost  Drivers 

Requirements  Understanding 

Nominal  ▼ 

Documentation 

Nominal 

▼  Personnel  Experience/Continuity 

High  ▼ 

Architecture  Understanding 

Nominal  ▼ 

#  and  Diversity  of  Installations/Platforms 

Nominal 

Process  Capability 

Nominal  ▼ 

Level  of  Service  Requirements 

Nominal  ▼ 

of  Recursive  Levels  in  the  Design 

Nominal 

Multisite  Coordination 

Nominal  ▼ 

Migration  Complexity 

Technology  Risk 

Very  High  ▼ 

Low  ▼ 

Stakeholder  Team  Cohesion 

Personnel/Team  Capability 

High 

Nominal 

Tool  Support 

Very  High  ▼ 

Maintenance  Off 

System  Labor  Rates 

Cost  per  Person-Month  (Dollars)  10000 

[  Calculate  | 

Figure  72.  COSYSMO  Inputs  for  ME-RBS 


B.  RESULTS 

With  the  assumptions  defined,  the  data  was  entered  into  the  COSYSMO  program 
to  determine  costs.  After  the  calculations,  there  were  three  outputs  worth  noting — effort, 
schedule,  and  cost.  Effort  is  the  estimated  amount  of  effort  required  to  complete  the 
project.  According  to  Valerdi,  effort  is  measured  in  person-months,  which  is  “a  unit  of 
measure  for  human  effort  which  usually  equals  152  person  hours”  (Valerdi  2005,  68). 
Schedule  is  an  approximation  of  the  length  of  time  to  complete  the  project,  and  is 
measured  in  months.  Cost,  measured  in  dollars,  is  the  estimate  of  the  cost  of  the  project. 
With  this  information,  COSYSMO  provides  insight  into  the  complexity  and  involvement 
of  the  project  as  a  whole. 

1.  OSRAP 

Eigure  73  shows  the  assumed  COSYSMO  results  for  the  OSRAP  system 
modifications. 
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Results 

Systems  Engineering 
Effort  =48.4  Person-months 
Schedule  =  5.4  Months 
Cost  =  $483693 

Total  Size  =220  Equivalent  Nominal  Requirements 


Acquisition  Effort  Distribution  (Person-Months) 


Phase / 
Activity 

Conceptualize 

Develop 

Operational 
Test  and 
Evaluation 

Transition 

to 

Operation 

Acquisition 
and  Supply 

0.9 

1.7 

0.4 

0.3 

Technical 

Management 

1.8 

3.1 

2.1 

1.2 

System 

Design 

4.9 

5.8 

2.5 

1.3 

Product 

Realization 

0.9 

2.2 

2.3 

1.8 

Product 

Evaluation 

2.7 

4.0 

6.0 

2.2 

Your  output  file  is  httD:/.''csse.usc.edu,1ools/data,''COSYSMO  Januar.  31  2014  00  00  20  665194. txt 

Created  by  Ray  Madachy  at  the  Naval  Postgraduate  School.  For  more  information  contact  him  at  rjmadach@nps.edu 

Figure  73.  COSYSMO  Results  for  OSRAP 


2.  ME-RBS 

Figure  74  shows  the  assumed  COSYSMO  results  for  the  ME-RBS  system 
modifications. 
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Results 

Systems  Engineering 
Effort  =40.8  Person-months 
Schedule  =  5.1  Months 
Cost  =  $408304 

Total  Size  =187  Equivalent  Nominal  Requirements 


Acquisition  Effort  Distribution  (Person-Months) 


Phase/ 

Activity 

Conceptualize 

Develop 

Operational 
Test  and 
Evaluation 

Transition 

to 

Operation 

Acquisition 
and  Supply 

0.8 

1.5 

0.4 

0.2 

Technical 

Management 

1.5 

2.6 

1.7 

1.0 

System 

Design 

4.2 

4.9 

2.1 

1.1 

Product 

Realization 

0.8 

1.8 

2.0 

1.5 

Product 

Evaluation 

2.3 

3.4 

5.1 

1.9 

Your  output  file  is  httD://csse.usc.edu,'1oQl5.''data.''COSYSMO  January  30  2014  23  57  24  691475.1x1 
Created  by  Ray  Madachy  at  the  Naval  Postgraduate  School.  For  more  information  contact  him  at  rjmadach@nps.edu 
Figure  74.  COSYSMO  Results  for  ME-RBS 


3.  SCMM  System  (Full  Development) 

Figure  75  shows  the  assumed  COSYSMO  results  for  the  SCMM  system  full 
development. 
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Results 

Systems  Engineering 
Effort  =209.9  Person-months 
Schedule  =  8.8  Months 
Cost  =  $2099281 

Total  Size  =386  Equivalent  Nominal  Requirements 


Acquisition  Effort  Distribution  (Person-Months) 


Phase / 
Activity 

Conceptualize 

Develop 

Operational 
Test  and 
Evaluation 

Transition 

to 

Operation 

Acquisition 
and  Supply 

4.1 

7.5 

1.9 

1.2 

Technical 

Management 

7.9 

13.6 

8.9 

5.4 

System 

Design 

21  4 

25.2 

10.7 

5.7 

Product 

Realization 

4.1 

9.4 

10.1 

7.9 
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Figure  75.  COSYSMO  Results  for  SCMM  (Full  Development) 

4.  SCMM  System  (Partial  Development) 

Figure  76  shows  the  assumed  COSYSMO  results  for  the  SCMM  system  (partial 
development). 
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Figure  76.  COSYSMO  Results  for  SCMM  (Partial  Development) 


5.  Effort 

ME-RBS  requires  the  least  amount  of  effort  per  person-month  based  on  the 
assumed  COSYSMO  output  for  effort,  as  shown  in  Figure  77. 


173 


Effort 


OSRAP  ME-RBS  SCMM  (Full)  SCMM  (Partial) 


Figure  77.  COSYSMO  Comparison  of  Effort  (Person-Months) 

6.  Schedule 

ME-RBS  has  the  shortest  schedule  based  on  the  assumed  COSYSMO  output  for 
schedule,  as  shown  in  Eigure  78. 
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OSRAP  ME-RBS  SCMM  (Full)  SCMM  (Partial) 


Figure  78.  COSYSMO  Comparison  of  Schedule(months) 


7.  Cost 

ME-RBS  is  the  least  costly  based  on  the  assumed  COSYSMO  output  for  cost,  as 
shown  in  Figure  79. 
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Cost 


OSRAP  ME-RBS  SCMM  (Full)  SCMM  (Partial) 

Figure  79.  COSYSMO  Comparison  of  Cost 

C.  RESULTS  OF  THE  COST  ANALYSIS 

Based  on  the  team’s  assumptions  the  cost,  effort,  and  time  to  implement  OSRAP 
or  ME-RBS  would  be  much  lower  than  implementing  the  SCMM  options,  as  either  full 
or  partial  development.  The  factors  used  in  COSYSMO  should  be  reevaluated  as 
additional  data  is  collected.  COSYSMO  can  also  be  used  to  perform  sensitivity  analysis 
using  pertinent  factors  as  trade-offs. 

D.  SUMMARY 

To  fully  compare  and  evaluate  the  alternatives  to  the  SCMM  system,  cost  analysis 
was  conducted  using  COSYSMO.  Four  alternatives  were  compared;  these  included 
OSRAP,  ME-RBS,  SCMM  complete  construction  and  SCMM  built-up  from  ME-RBS. 
Multiple  factors  were  used  to  determine  costs.  Due  to  the  limitation  of  information 
regarding  the  alternatives,  several  of  the  factors  were  based  on  comparative  assumptions. 
Based  on  the  results  of  the  cost  analysis,  the  time,  effort,  and  cost  required  to  implement 
OSRAP  or  ME-RBS  proved  to  be  lower  than  implementing  the  SCMM  option.  The 
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results  from  the  cost  analysis  provided  an  additional  layer  of  assessment  and  review, 
which  in  turn,  enforced  and  validated  the  final  results  of  the  capstone  project. 
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IX.  RISK  ANALYSIS 


Blanchard  and  Fabrycky  state  that  risk  is  “...inherent  in  any  formal  program 
activity”  (2011,  690),  and  that  it  is  “...the  potential  that  something  will  go  wrong  as  a 
result  of  one  or  a  series  of  events”  (2011,  690).  As  such,  “...a  critical  activity  in  the 
management  of  a  systems  engineering  program  is  the  establishment  of  a  risk  management 
capability  and  the  development  of  a  risk  management  plan”  (Blanchard  and  Fabrycky 
2011,  693).  Risk  management  addresses  the  processes  for  identifying,  assessing, 
mitigating,  and  monitoring  the  risks  expected  or  encountered  during  a  project’s  life  cycle 
(Department  of  Defense  2006).  One  of  key  activities  in  risk  management  is  the  analysis 
of  the  identified  risks.  The  goal  of  risk  analysis,  according  to  Blanchard  and  Fabrycky,  is 
to  “...determine  the  way(s)  in  which  the  risk  can  be  eliminated  or  minimized  if  not 
eliminated  altogether”  (2011,  692). 

Additional  details  on  the  risk  management  approach  utilized  by  the  team  can  be 
found  in  the  SEMP  (for  a  copy  please  contact  Mr.  Raymond  Chun  at 
Ravmond.Chun@navv.mil)  and  in  the  appendix  titled  Supply  Chain  Management  Model 
Risk  Management  Plan. 

A.  RISK  ANALYSIS  PROCESS 

When  identifying  risks  in  the  capstone  project,  the  team  categorized  them  into 
three  areas:  program  management  risk,  technical  risk  and  overall  program  risk.  Program 
management  risks  are  those  risks  related  to  the  team’s  progress  on  programmatic  goals 
and  objectives  which  took  into  account  the  team’s  project  master  schedule,  stakeholder 
expectations,  and  any  other  metrics  within  program  management.  Technical  risk  related 
to  the  team’s  progress  on  the  technical  goals  and  objectives  and  again  took  into  account 
the  team’s  project  master  schedule,  stakeholder  expectations,  and  any  other  metrics 
within  technical  execution  of  the  capstone  project.  Overall  program  risks  included  risks 
associated  with  implementation,  operation,  and  retirement  of  the  system. 

Each  program  management,  technical,  and  overall  program  risk  was  further 
classified  as  either  a  system  risk  or  project  risk.  A  system  risk  is  directly  related  to  the 
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technical  aspects  of  the  system;  while  a  project  risk  is  directly  related  to  the  team’s  ability 
to  complete  the  capstone  project.  Two  examples  of  the  project  risks  that  were  identified 
by  the  team  included  issues  like  balancing  the  workload  between  the  capstone  and  the 
other  classes  taken  concurrently,  and  working  around  team  member  absences. 

The  system  risks  identified  were:  interoperability  risk,  operational  risk,  classified 
information  sharing,  implementation  risk  and  retirement  risk.  Interoperability  risk 
focused  on  the  risk  of  the  supply  chain  management  system  not  being  compatible  with 
current  and  future  Navy  software  systems  that  it  must  interact  with,  such  as  Navy  ERP, 
CDMD-OA,  Navy  Marine  Corps  Intranet  (NMCI),  etc.  The  possible  risk  of  needing 
information  from  classified  databases  was  another  system  risk  identified  by  the  team. 
While  developing  the  supply  chain  management  system  requirements  and  scoping  the 
system,  it  was  determined  that  the  model  may  need  access  to  information  that  resides  in 
classified  databases,  which  would  be  a  security  concern.  Operational  risk  encompassed 
the  various  risks  associated  with  personnel  training.  Implementation  risk  incorporated  the 
different  risks  with  implementing  a  supply  chain  management  system  such  as  unrealistic 
user  expectations  or  application  complexity.  Retirement  risk  comprised  risks  associated 
with  retiring  a  system  at  the  end  of  its  life  cycle.  Once  risks  were  identified,  the  team’s 
risk  management  plan  was  utilized  to  analyze,  mitigate,  and  monitor  these  risks. 

B.  RISK  MITIGATION 

Risk  mitigation  is  defined  in  the  Risk  Management  Guide  for  DOD  Acquisition, 
the  sixth  edition  as  “the  activity  that  identifies,  evaluates  and  selects  the  best  option  to  set 
a  risk  at  an  acceptable  level,  based  on  project  objectives  and  constraints”  (Department  of 
Defense  2006,  33).  Once  a  risk  has  been  identified,  four  tools  are  used  to  evaluate  and 
treat  the  risk:  avoid,  assume,  control  or  transfer.  Avoiding  risk  entails  utilizing  an 
approach  to  “eliminate  the  root  cause  and/or  consequence  of  the  risk,”  therefore  avoiding 
the  risk  (Department  of  Defense  2006,  18).  The  concern  about  the  “classified  information 
sharing  risk”  (accessing  classified  information  via  the  Secret  Internet  Protocol  Router 
Network  [SIPRNET])  was  avoided  by  determining  whether  the  classified  data  was  really 
required  for  the  SCMM  system,  and  if  so,  whether  it  could  be  entered  as  an  unclassified 
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user  input  rather  than  having  the  information  pushed  from  the  classified  databases.  It  was 
confirmed  that  the  information  was  required  but  that  the  users  could  enter  it  as  an 
unclassified  input;  therefore,  the  risk  was  avoided  by  not  connecting  the  SCMM  system 
to  a  classified  database.  If  a  risk  can’t  be  avoided  then  it  becomes  an  assumed  risk  that 
will  have  to  be  monitored.  Another  tool  used  in  risk  mitigation  is  controlling  the  risk. 
This  tool  examines  the  root  cause  or  consequence  of  a  risk  and  uses  mitigation  techniques 
to  reduce  the  risk  to  an  acceptable  level  (Department  of  Defense  2006).  Transferring  risk 
transfers  mitigation  of  the  risk  to  another  organization  or  entity.  The  team  utilized  these 
tools  as  applicable  in  mitigating  the  risks  identified  by  the  team  as  the  project  progressed. 
As  risks  were  successfully  mitigated,  they  were  retired  from  being  actively  tracked  / 
monitored  by  the  team. 


When  it  came  to  mitigating  risks  in  the  capstone  project,  the  team  reviewed  the 
identified  system  risks  documented  in  the  team’s  Risk  Management  Spreadsheet  and  then 
identified  different  mitigation  strategies  that  could  be  used  to  either  minimize  or 
eliminate  the  risks.  Table  12  shows  the  team’s  Risk  Management  Spreadsheet  for  the 
SCMM  system  risks,  which  details  the  active  system  risks  that  the  team  was  tracking  and 
their  associated  mitigation  strategies.  Since  the  team  avoided  the  “classified  information 
sharing”  risk,  which  was  system  risk  #2,  it  is  not  listed  in  the  table.  The  project  risk 


portion  of  the  Risk  Management  Spreadsheet  can  be  found  in  the  Supply  Chain 


Management  Model  Risk  Management  Plan  appendix. 


Risk  Management  Status — System  Risks 


Risk 

No. 


Risk  Area 


Technical 

Risk 


Overall 

Program 

Risk 


Narrative 


Interoperability 
with  other 
systems 


Retirement  Risk 


Mitigation 
Strategy 
With  other 
databases  and 
software  systems: 
Check  software 
interfaces  in  the 
design  phase 
rather  than  waiting 
until  integration 
testing _ 

Retiring  the 
system  cannot  be 
mitigated. 
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Risk  Management  Status — 

System  Risks 

Risk 

No. 

Risk  Area 

Narrative 

Likelihood 

Consequence 

Mitigation 

Strategy 

4 

Technical 

Risk 

Operational 

Risks 

2 

3 

Training  plan  will 
be  developed  and 
tracked  to  identify 
required  training. 

1)  Unrealistic  user 
expectations:  To 
gain  sponsor 
acceptance,  we 
met  several  times 
to  discuss 

5 

Overall 

Program 

Risk 

Implementation 

Risks 

3 

3 

implementation 

approach 

2)  Application 
complexity:  The 
process  model  was 
monitored 
throughout  the 
development 
phase  to  ensure  it 
was  working. 

Table  12.  Risk  Management  Spreadsheet  for  System  Risk 


The  risk  management  spreadsheet  recorded  the  type  of  risk,  the  specific 
risk/narrative,  as  well  as  the  likelihood,  consequence  and  risk  mitigation  strategy  for  each 
risk.  The  mitigation  strategies  for  the  system  risks  are  tailored  to  each  individual  risk. 
Mitigating  the  interoperability  risks  will  focus  on  examining  the  software  interfaces  that 
the  system  will  have  with  the  different  databases  from  which  it  will  be  receiving 
information.  In  order  to  control  this  risk,  a  future  team  should  check  software  interfaces 
in  the  design  phase  rather  than  waiting  until  integration  testing,  to  ensure  interoperability 
and  reduce  costs.  The  retirement  risk  is  minimal;  therefore,  there  is  no  mitigation  plan  for 
this  risk.  The  operational  risks  mitigation  strategy  will  be  to  develop  a  training  plan  based 
on  the  training  requirements  for  users  to  operate  the  system.  The  final  system  risk  the 
team  identified  was  implementation  risks.  One  of  these  risks  was  unrealistic  user 
expectations.  This  can  be  mitigated  by  consistently  meeting  with  the  sponsor  to  ensure 
the  team’s  efforts  stay  on  track  and  meet  with  the  sponsor’s  approval.  The  complexity  of 
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the  system  application  is  another  implementation  risk.  It  can  be  mitigated  by 
continuously  monitoring  the  process  model  throughout  the  development  process  to  ensure 
the  final  product  is  user-friendly. 

C.  RISK  ANALYSIS  OF  ALTERNATIVES 

The  four  alternatives  evaluated  in  the  cost  analysis,  OSRAP,  ME-RBS,  SCMM 
(full),  and  SCMM  (partial),  were  assessed  for  system  risks.  A  risk  analysis  was  conducted 
for  interoperability,  operational,  implementation,  and  retirement  risks.  Interoperability 
regards  the  system’s  ability  to  allow  for  information  exchange  with  external  databases, 
operational  risk  is  the  risk  associated  with  the  users’  level  of  comfort  with  the  system 
(e.g.,  user  interface,  ease  of  use),  implementation  pertains  to  the  risks  associated  with  the 
users  adopting  the  system  for  use,  and  retirement  is  concerned  with  the  ease  of  system 
disposal. 

Using  the  risk  management  process,  a  risk  score  was  assigned  to  each  of  the 
alternative  systems  based  on  the  information  obtained  from  the  AoA  and  the  cost  analysis 
and  how  that  information  related  to  the  system  risks  contained  in  the  risk  tracking 
spreadsheet.  The  risk  scores  were  then  plotted  in  a  risk  matrix  for  each  alternative.  The 
risk  matrices  depict  the  likelihood  and  consequence  of  the  risks  identified  for  each 
alternative.  The  level  of  risk  was  reported  as  low  (green),  moderate  (yellow),  or  high 
(red).  Figures  80-82  display  the  results  of  the  risk  assessment  for  the  various  systems. 
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Figure  80.  OSRAP  and  ME-RBS  System  Risk  Matrix 
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Figure  8 1 . 


SCMM  (Full)  System  Risk  Matrix 
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Figure  82.  SCMM  (Partial)  System  Risk  Matrix 

Modification  of  OSRAP  and  ME-RBS  present  the  lowest  risk  overall  because 
these  systems  are  currently  in  the  operational  life  cycle  phase.  Designing  a  completely 
new  SCMM  system  (SCMM  [full])  has  the  highest  likelihood  and  consequence  for  all 
identified  risks.  The  SCMM  (partial),  which  entails  modification  of  the  existing  ME-RBS 
model  and  makes  it  a  standalone  SCMM  system,  has  lower  interoperability  and 
implementation  risks  than  the  SCMM  (full),  due  to  the  opportunity  to  leverage  off  an 
existing  system. 

D.  SUMMARY 

Risk  management  was  conducted  early  in  the  systems  life-cycle  and  continued 
throughout  the  project.  This  iterative  process  included  risk  identification,  risk  assessment, 
risk  mitigation,  and  risk  reporting.  Strategies  such  as  avoid,  assume,  control  or  transfer, 
were  implemented  to  mitigate  the  effects  of  the  risks. 

A  risk  analysis  based  on  the  information  from  the  AoA  and  cost  analyses  was 
conducted  on  four  alternatives.  The  risk  analysis  included  the  system  risks  for 
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interoperability,  operation,  implementation,  and  retirement.  The  results  of  the  analysis 
were  captured  on  risk  matrices,  which  show  that  OSRAP  and  ME-RBS  have  lower  risk 
scores  than  SCMM  (full)  and  SCMM  (partial). 

Through  successful  risk  management  the  likelihood  and  consequence  of  some  of 
the  identified  risks  were  reduced.  Results  of  the  risk  analysis  were  updated  periodically 
and  reported  to  the  team.  Risk  management  is  an  ongoing  activity  that  should  continue 
throughout  the  life  of  the  project. 
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X.  CONCLUSION 


A.  SYNOPSIS 

This  project  began  with  the  sponsor’s  (Mr.  Howard  of  NSWC  PHD)  initial 
problem  statement:  Current  surface  Navy  supply  chain  models  do  not  support  a  modular 
architecture  and  an  off  ship  maintenance  support  structure  requiring  multiple  logistics 
and  repair  nodes  to  reflect  optimal  manning  or  constrained  physical  and  weight 
constrained  supply  points.  As  part  of  acquisition  strategies,  an  increasing  number  of 
ships  are  looking  at  a  modular  or  flexible  design  to  support  rapid  introduction  of 
capability.  As  part  of  this  capability,  a  process  and  approach  for  optimizing  the  spares 
allocation  at  the  war  fighters  ’  level  and  to  support  maintenance  nodes  is  required. 

Team  RSRP  conducted  a  literature  review  of  available  published  materials  to 
research  and  substantiate  the  challenges  of  the  current  supply  chain  and  to  identify 
relevant  terms  included  in  the  problem  statement.  The  team  then  developed  questions  to 
focus  the  research  to  areas  related  to  modular  or  flexible  design  ships.  The  research 
questions  were  posed  in  subsequent  interviews  to  the  sponsor  to  understand  the 
organizations  that  are  involved  with  ship  sustainment  operations  and  would  be  affected 
by  the  development  of  a  new  SCM  model  supporting  modular  ship  classes.  Through  an 
iterative  process  of  interviews  with  the  sponsor  and  topic  research,  the  final  problem 
statement  was  defined:  As  the  U.S.  Navy  drives  toward  modular  and  flexible  designs,  the 
currently  used  surface  Navy  SCM  models  do  not  support  modular  or  flexible  design 
ships.  These  ships  require  an  off-ship  maintenance  support  structure  consisting  of 
multiple  logistics  and  repair  nodes  due  to  shipboard  constraints  including  manning, 
space,  and  weight. 

The  project  team  finalized  the  identification  of  the  relevant  stakeholders  for  the 
SCMM  system  and  established  the  individual  stakeholder  needs  for  the  system.  The 
finalized  effective  need  statement  is:  The  stakeholders  need  information  to  determine 
sparing  of  parts  at  existing  and  multiple  supply  points  in  order  to  support  the  Navy ’s 
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modular/flexible  ships  within  the  constraints  of  manning,  space,  weight,  location,  and 
cost/budget. 

The  gap,  which  is  the  difference  between  the  current  state  of  the  system  and  how 
the  stakeholder  needs  the  system  to  perform  and  operate,  was  identified  as:  The 
systems/programs  currently  in  use  for  determining  spare  parts  allocations  do  not  provide 
information  that  takes  into  account  the  ability  to  modify  ships  rapidly  to  introduce 
warfare  specific  capability  through  the  use  of  mission  modules  nor  do  they  take  into 
account  shipboard  constraints  including  manning,  space,  and  weight  which  impact  ships  ’ 
and  fleet’s  readiness  and  operational  availability . 

To  develop  the  SCMM  system,  a  suitable  SEP  was  determined  for  the  project. 
The  team  tailored  the  vee  SEP  to  reflect  the  unique  needs  of  the  SCMM  system 
development.  This  tailored  vee  included  the  following  main  developmental  process 
phases:  needs  analysis,  system  requirements,  system  architecture,  conceptual  design, 
modeling  and  simulation,  system  integration  and  test,  component  verification,  system 
analysis,  and  system  validation. 

The  research  conducted  following  the  vee  SEP  confirms  the  need  for  the  SCMM 
system.  The  project’s  outputs  provide  a  basis  for  continuation  of  system  development. 
The  outputs  include  a  use  case  based  on  operational  scenarios,  EEBDs,  HBDs,  a  matrix 
allocating  the  inputs  and  outputs  to  functions,  an  ICOM/IDEEO  diagram,  a  context 
diagram,  system  requirements  (including  functional  requirements),  an  N-squared 
diagram,  DODAE  views  (CV,  OVs,  and  SVs),  recommended  existing  alternatives 
suitable  for  adaptation  to  meet  the  SCMM  system’s  requirements,  simulations  of  the 
SCMM  system,  a  test  strategy  and  plan,  cost  analysis  information,  and  a  risk  management 
plan. 

B.  RESULTS 

Based  on  the  analyses  conducted  during  the  SEP,  the  team  concluded  that  the 
Multi-Echelon  Readiness  Based  Sparing  (ME-RBS)  system  is  the  best  alternative  suitable 
for  adaptation  to  support  the  stakeholders’  needs  and  requirements.  This  model  requires 
additional  research  to  determine  whether  modification  is  viable  in  terms  of  design  and 
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cost.  Another  option  is  the  development  of  a  new  system  rather  than  adaptation  of  an 
existing  system.  This  option  would  be  preferred  if  the  ME-RBS  system’s  design  could 
not  be  altered  and/or  if  the  cost  was  above  that  of  new  system  development.  Initial  cost 
analysis,  based  on  assumptions,  and  risk  analysis  indicate  that  adapting  the  ME-RBS 
system  would  be  less  costly  and  have  lower  risk  than  constructing  a  new  system. 

C.  RECOMMENDATIONS 

The  team  recommends  that  research  and  analysis  continue  in  support  of  the 
development  of  the  SCMM  system,  whether  it  is  the  alteration  of  the  ME-RBS  system  or 
the  creation  of  a  new  system,  to  meet  the  identified  stakeholders’  needs.  Additional 
recommendations  include: 

•  Continue  developing  the  functional  performance  requirements  and  system 
requirements. 

•  Continue  decomposing  the  functions. 

•  Develop  additional  architectural  views  such  as  the  OV-3  (operational 
resource  flows  exchanged  between  operational  activities  and  locations) 
and  OV-4  (shows  organizational  structures  and  interactions). 

•  Verify  performance  characteristics. 

•  Identify  design  issues. 

•  Conduct  trade-off  studies,  including  readiness  and  maturity  of  the  system 
design. 

•  Einalize  component  selection. 

•  Conduct  component  verification  through  an  effective  combination  of 
analysis,  inspection,  demonstration,  and  testing  that  gauges  the  maturity  of 
each  component  of  the  design  (i.e.,  software  (S/W)  and  supportability) 
prior  to  integrating  the  overall  system  design  solution. 

•  Continue  system  validation  throughout  the  design  of  the  SCMM  system  by 
performing  progressive  and  iterative  integrated  system  testing  to  validate 
the  maturity  of  the  system  and  assess  overall  system  readiness. 

•  Reevaluate  the  factors  used  in  COSYSMO  as  additional  data  is  collected. 

•  Perform  sensitivity  analysis  with  COSYSMO  using  pertinent  factors  as 
trade-offs. 

•  Mitigate  the  interoperability  risks  by  examining  the  software  interfaces 
that  the  system  will  have  with  the  different  databases  from  which  it  will  be 
receiving  information. 
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•  Mitigate  the  operational  risks  by  developing  a  training  plan  based  on  the 
training  requirements  for  users  to  operate  the  system. 

•  Mitigate  implementation  risks  such  as  unrealistic  user  expectations  and, 
system  complexity. 

If  the  recommendation  to  continue  with  the  development  of  the  SCMM  system  is 
not  pursued,  the  Navy’s  modular  or  flexible  ships  will  not  be  supported  within  the 
constraints  of  manning,  space,  weight,  location,  and  cost/budget  by  the  current  RBS 
models  in  use.  The  impact  would  be  a  decrease  in  ships’  and  fleet’s  readiness  and 
operational  availability. 

It  is  hoped  that  additional  research  supports  further  development  and  that  analyses 
are  conducted  in  support  of  finalizing  the  design  of  this  SCMM  system. 
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APPENDIX  A.  FUNCTIONAL  FLOW  BLOCK  DIAGRAM 


The  FFBD  is  a  very  large  plottable  diagram  that  has  been  cut  into  sections  here  to 
allow  readers  to  print  and  assemble  for  better  viewing  purposes,  if  so  desired.  See  Figures 
83-86. 
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Figure  83.  SCMM  System  FFBD  Seetion  A 
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Figure  84.  SCMM  System  FFBD  Section  B 
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Figure  85.  SCMM  System  FFBD  Section  C 
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Figure  86.  SCMM  System  Section  D 
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APPENDIX  B.  ADDITIONAL  DODAF  VIEWS  INFORMATION 


The  OV-2  shown  in  the  DODAF  Views  section  of  the  System  Architecture 
chapter  helped  to  place  the  SCMM  system  in  an  operational  context  depicting  the 
required  resources  from  each  entity.  It  also  helped  to  ensure  that  the  flow  of  resources 
was  sound  and  that  the  necessary  resources  were  accounted  for.  The  specific 


organizational  resource  flows  are  captured  in  a  matrix  that  can  be  viewed  in  Table  13. 


Organization 

(Component) 

Name 

Resource  Eink 

ERP 

ERP  Parts  Information 

Failure 

Reporting 

System 

Eailure  Rate/MTBE 

Homeports 

Parts  from  DEA  to  Homeports 

Parts  from  ISEA  to  Homeports 

Parts  from  MPSE  to  Homeports 

Parts  from  NAVSUP  to  Homeports 

NDE:  AMPS 

Planned  changes  to  mission  module’s  configuration/dates  for 
changes 

Planned  changes  to  ship’s  configuration/dates  for  changes 

NDE:  CDMD- 
OA 

Ship/Mission  Module  Configuration 

CDMD-OA  Parts  Information 

OCONUS 

Warehouses 

Parts  from  DEA  to  OCONUS  Warehouses 

Parts  from  ISEA  to  OCONUS  Warehouses 

Parts  from  MPSE  to  OCONUS  Warehouses 

Parts  from  NAVSUP  to  OCONUS  Warehouses 

Ships 

Parts  from  DEA  to  Ships 

Parts  from  ISEA  to  Ships 

Parts  from  MPSE  to  Ships 

Parts  from  NAVSUP  to  Ships 

Shore-based 

Maintenance 

Eacilities 

Parts  from  DEA  to  Shore-based  Maintenance  Eacilities 

Parts  from  ISEA  to  Shore-based  Maintenance  Eacilities 

Parts  from  MPSE  to  Shore-based  Maintenance  Eacilities 

Parts  from  NAVSUP  to  Shore-based  Maintenance  Eacilities 

Supply  Chain 
Management 

CDMD-OA  Parts  Information 

DEA  Query  Inputs 
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Organization 

(Component) 

Name 

Resource  Link 

Model 

ERP  Parts  Information 

Failure  Rate/MTBF 

ISEA  Query  Inputs 

MPSF  Query  Inputs 

NAVSUP  Query  Inputs 

Parts  Allocation  Information  to  DLA 

Parts  Allocation  Information  to  ISEA 

Parts  Allocation  Information  to  MPSF 

Parts  Allocation  Information  to  NAVSUP 

Planned  changes  to  mission  module’s  configuration/dates  for 
changes 

Planned  changes  to  ship’s  configuration/dates  for  changes 

Sensitivity  Analysis  Information  to  DLA 

Sensitivity  Analysis  Information  to  ISEA 

Sensitivity  Analysis  Information  to  MPSF 

Sensitivity  Analysis  Information  to  NAVSUP 

Ship/Mission  Module  Configuration 

User:  DLA 

DLA  Query  Inputs 

Parts  Allocation  Information  to  DLA 

Parts  from  DLA  to  Homeports 

Parts  from  DLA  to  OCONUS  Warehouses 

Parts  from  DLA  to  Ships 

Parts  from  DLA  to  Shore-based  Maintenance  Facilities 

Sensitivity  Analysis  Information  to  DLA 

User:  ISEA 

ISEA  Query  Inputs 

Parts  Allocation  Information  to  ISEA 

Parts  from  ISEA  to  Homeports 

Parts  from  ISEA  to  OCONUS  Warehouses 

Parts  from  ISEA  to  Ships 

Parts  from  ISEA  to  Shore-based  Maintenance  Facilities 

Sensitivity  Analysis  Information  to  ISEA 

User:  MPSF 

MPSF  Query  Inputs 

Parts  Allocation  Information  to  MPSF 

Parts  from  MPSF  to  Homeports 

Parts  from  MPSF  to  OCONUS  Warehouses 

Parts  from  MPSF  to  Ships 
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Organization 

(Component) 

Name 

Resource  Link 

Parts  from  MPSF  to  Shore-based  Maintenance  Facilities 

Sensitivity  Analysis  Information  to  MPSF 

User:  NAVSUP 

NAVSUP  Query  Inputs 

Parts  Allocation  Information  to  NAVSUP 

Parts  from  NAVSUP  to  Homeports 

Parts  from  NAVSUP  to  OCONUS  Warehouses 

Parts  from  NAVSUP  to  Ships 

Parts  from  NAVSUP  to  Shore-based  Maintenance  Facilities 

Sensitivity  Analysis  Information  to  NAVSUP 

Table  13.  SCMM  System  Organizational  Resources  Linkage  Matrix  depicted  by 

OV-2 
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APPENDIX  C.  ANALYSIS  OF  ALTERNATIVES  SCORING 

MATRIX 


Figure  87  displays  the  AoA  scoring  matrix.  Each  of  the  23  models  was  evaluated 
against  each  criterion  using  a  score  between  zero  to  five.  A  model  that  completely  met 
the  criteria  was  assigned  a  score  of  five.  A  zero  score  meant  the  model  did  not  include 
that  criterion.  The  resultant  score  under  each  criterion  was  then  multiplied  by  its 
corresponding  weight.  The  final  scoring  was  the  summation  of  the  weight-times-score  for 
each  criterion.  The  objective  of  this  analysis  was  to  select  the  highest  performing  existing 
system  alternatives.  An  alternative  that  completely  met  all  six  criteria  will  have  a  final 
score  of  5.  The  highest  remaining  alternatives  would  be  further  analyzed  and  researched 
in  order  to  recommend  use  of,  modification  to,  or  new  development  of  a  model  to  meet 
the  requirements  of  the  stakeholders. 


201 


Model  Weight:  Zero  to  5 
None  =  0  to  Most  =  5 


Criteria 

Space  input 

0.1667 

0 

1 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

1 

0 

0 

0 

0 

0 

0 

0 

0 

0 

Weight  input 

0.1667 

0 

2 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

2 

0 

0 

0 

0 

0 

0 

0 

0 

0 

Operational  Availability  ir 

0.1667 

2 

5 

2 

5 

2 

1 

3 

3 

2 

3 

1 

5 

2 

5 

1 

4 

3 

2 

2 

4 

2 

3 

3 

Cost  input 

0.1667 

3 

3 

1 

3 

1 

0 

2 

3 

1 

1 

1 

4 

4 

3 

1 

1 

1 

0 

1 

2 

0 

3 

1 

Muiti-Nodal  input 

0.1667 

0 

0 

1 

3 

0 

0 

0 

1 

0 

0 

0 

4 

0 

1 

0 

0 

3 

0 

1 

2 

0 

0 

0 

Multi-Mission  input 

0.1667 

0 

0 

1 

4 

1 

1 

0 

0 

0 

0 

0 

4 

0 
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0 

1 

0 

0 

0 

0 

1 

1 

0 
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0.3333 
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1.0000 
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0.6667 

1.3333 

0.5000 

1.1667 

0.6667 
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-O- 


-O- 


-E3- 


Figure  87.  Analysis  of  Alternatives  Scoring  Matrix 
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APPENDIX  D.  EXCEL  SIMULATION  MACRO 


An  Excel  simulation  was  created  to  emulate  the  input  data,  processing,  and  output 
report  that  was  expected  of  the  system.  A  macro  was  developed  to  delete  data  that  was 
not  applicable  to  the  user’s  input.  Excel  consolidated  data  that  was  coming  from  two 
sample  databases.  Once  the  data  was  consolidated  the  Excel  file  automatically  applied  the 
sort  and  rank  with  highest  criticality  and  lowest  MTBE.  However,  this  still  included  all 
the  data,  even  the  data  that  was  not  applicable  to  the  user’s  inputs.  In  order  to  delete  the 
data  that  was  not  applicable  to  the  user’s  needs,  the  example  code  of  “=IE(‘User 
Input’ !$A$1=‘ Total  Database’ !$I$2,IE(‘User  Input’ !$A$2=‘Total  Database’ !$H$2,’ Total 
Database’ !B2,0),0)  was  used  to  create  a  line  of  “0”‘s  in  the  non-applicable  lines  of  data. 
The  “0”  lines  were  deleted  and  the  resulting  data  was  placed  in  the  “Output  Report”  tab. 
This  was  accomplished  with  the  following  macro: 

Sub  Macro2() 


‘  Macro2  Macro 


Sheets(“Total  Database  2”). Select 
Columns(“A:I”).Select 
Selection. Copy 

Sheets(“Output  Report”).  Select 
Columns(“A:I”).Select 
ActiveSheet.Paste 
Range(“J5”).Select 
Application.CutCopyMode  =  Ealse 
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Selection. Delete  Shift:=xlUp 
Range(“M23”).Select 
ActiveWindow.ScrollRow  =  9 
ActiveWindow.ScrollRow  =  8 
ActiveWindow.ScrollRow  =  7 
ActiveWindow.ScrollRow  =  6 
ActiveWindow.ScrollRow  =  5 
ActiveWindow.ScrollRow  =  4 
ActiveWindow.ScrollRow  =  3 
ActiveWindow.ScrollRow  =  2 
ActiveWindow.ScrollRow  =  1 
Range(“G22”). Select 
Dim  Ir  As  Long,  i  As  Long 
Ir  =  Range(“Al”).End(xlDown).Row 

For  i  =  Ir  To  1  Step  -1 
If  Cells(lr,  l).Value  =  “0”  Then 
Cells(lr,  l).EntireRow. Delete 
End  If 
Ir  =  Ir  -  I 
Next  i 
End  Sub 
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APPENDIX  E.  ADDITIONAL  AND  EXPANDED  TEST 

DOCUMENTATION 


This  appendix  contains  the  test  and  measures  metrics  table,  test  results  report,  and 
the  configuration  control  /  change  management  spreadsheets  used  and  produced  during 
the  system  integration  and  test  phase. 

A.  TEST  MEASURES  AND  METRICS  TABLE 

The  defined  functional  and  nonfunctional  requirements  of  the  SCMM  system 
were  tested.  Each  of  the  identified  requirements  was  determined  to  be  testable  or  not 
testable,  and  then  was  incorporated  into  a  testing  schema.  This  became  the  test  plan  and 
includes  the  test  approach  used  for  each  requirement.  The  test  measures  and  metrics  for 
the  simulation  of  the  SCMM  system  are  listed  in  Table  14.  The  table  includes  the  test 
approach  used  for  each  requirement  to  be  tested. 


Requirement 

Description 

Testing  Approach 

1 

SCMM  System 

Function 

The  system  shall 
provide  the  user  with 
information  on  parts 
allocation. 

Sub-requirements  will  be 
tested. 

1.1 

Receive  Input 

The  system  shall 
receive  user  input. 

Sub-requirements  will  be 
tested. 

1.1.1 

Ship  Hull  Number 

The  system  shall 
receive  ship  hull 
number. 

Test  to  verify  SCMM 
receives  the  ship  hull 
number.  Can  be  visual 
confirmation. 

1.1.2 

Ship  Seaframe  System 

The  system  shall 
receive  ship’s 
seaframe  system(s). 

Test  to  verify  SCMM 
receives  the  ship’s 
seaframe  system.  Can  be 
visual  confirmation. 
Multiple  seaframes  must 
be  able  to  be  entered. 

1.1.3 

Ship  Mission  Module 
System 

The  system  shall 
receive  ship’s  mission 
module(s). 

Test  to  verify  SCMM 
receives  the  ship  mission 
module.  Can  be  visual 
confirmation.  Multiple 
mission  modules  must  be 
able  to  be  entered. 
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Requirement 

Description 

Testing  Approach 

1.1.4 

Ship’s 

Dimensions/ Available 
Space 

The  system  shall 
receive  ship’s 
available  space  and 
dimensions  allowance. 

Test  to  verify  SCMM 
receives  the  ship’s 
available  space  and 
dimension  allowance. 

Can  be  visual 
confirmation. 

1.1.5 

Ship’s  Available 

Weight  Allowance 

The  system  shall 
receive  ship’s 
available  weight 
allowance  for  parts. 

Test  to  verify  SCMM 
receives  the  ship’s 
available  weight 
allowance  for  parts.  Can 
be  visual  confirmation. 

1.1.6 

Ship’s  Availability 
Requirement 

The  system  shall 
receive  ship’s 
availability 
requirement. 

Test  to  verify  SCMM 
receives  the  ship’s 
availability  requirement. 
Can  be  visual 
confirmation. 

1.2 

Provide  Output 

The  system  shall 
provide  a  report  of  the 
output. 

Test  to  verify  SCMM 
outputs  report.  Report 
may  be  a  separate  file  or 
screenshot.  Can  be  visual 
confirmation. 

1.2.1 

Ship  Spare  Allocation 
Model 

The  system  shall 
provide  a  report 
detailing  spares 
allocation  on  ship. 

Test  and  verify  SCMM 
report  displays  spares 
allocation  on  ship. 

1.2.2 

Mission  Module 
Container  Spare 
Allocation  Model 

The  system  shall 
provide  a  report 
detailing  spares 
allocation  in  mission 
module  containers. 

Test  and  verify  SCMM 
report  spares  allocation  in 
mission  module 
containers. 

1.2.3 

Facility  Spare  Model 

The  system  shall 
provide  a  report 
detailing  spares 
allocation  at  land- 
based  maintenance 
facilities. 

Test  and  verify  SCMM 
report  displays  spares 
allocation  at  land-based 
maintenance  facilities. 

1.2.4 

MPSF  Facility  Space 
Allocation  Model 

The  system  shall 
provide  a  report 
detailing  spares 
allocation  at  MPSF 
facilities. 

Test  and  verify  SCMM 
report  displays  spares 
allocation  at  MPSF 
facilities. 
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Requirement 

Description 

Testing  Approach 

1.2.5 

Warehouse  Spare 

Model 

The  system  shall 
provide  a  report 
detailing  spares 
allocation  at 

OCONUS  warehouse 
locations. 

Test  and  verify  SCMM 
report  displays  spares 
allocation  at  OCONUS 
warehouse  locations. 

1.2.6 

Homeport  Spare 

Model 

The  system  shall 
provide  a  report 
detailing  homeport 
spares  allocation. 

Test  and  verify  SCMM 
report  displays  spares 
allocation  at  homeport 
locations. 

1.2.7 

Display  Summary 
Report  Spare 

Allocation  Printout 

The  system  shall 
provide  a  report 
summary  of  all  spare 
models  via  hardcopy. 

Test  and  verify  SCMM 
report  displays  a 
summary  of  all  spare 
models. 

1.2.8 

Display  Summary 
Report  Spare 

Allocation. 

The  system  shall 
provide  a  report 
summary  of  all  spare 
models  via  display  of 
the  data. 

Test  and  verify  SCMM 
report  displays  a 
summary  of  all  spare 
models. 

1.3 

Interoperability 

Will  not  be  tested. 

1.3.1 

User 

The  system  shall  be 
interoperable  with  the 
systems  of  the  user. 

Will  not  be  tested. 

1.3.2 

NAVSUP 

The  system  shall  be 
interoperable  with  the 
system  used  by 
NAVSUP  WSS. 

Will  not  be  tested. 

1.3.3 

MPSF 

The  system  shall  be 
interoperable  with  the 
systems  used  by 
maintenance  sites. 

Will  not  be  tested. 

1.3.4 

ISEA 

The  system  shall  be 
interoperable  with  the 
systems  used  by  ISEA. 

Will  not  be  tested. 

1.3.5 

Enterprise  Resource 
Planning  (ERP) 

The  system  shall  be 
interoperable  with  the 
One  Touch  Support 
(or  NAVSUP  ERP). 

Will  not  be  tested. 

1.3.6 

AMPS 

The  system  shall  be 
interoperable  with 
AMPS  (Afloat  Master 
Planning  System). 

Will  not  be  tested. 
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Requirement 

Description 

Testing  Approach 

1.3.7 

CDMD-OA 

The  system  shall  be 
interoperable  with 
CDMD-OA. 

Will  not  be  tested. 

1.4 

System  Functionality 

The  system  shall  be 
functional. 

Sub-requirements  will  be 
tested. 

1.4.1 

Store  Data  and  Output 
to  Excel 

The  system  shall  be 
compatible  to  store 
data  and  output  to 

Excel. 

Test  and  verify  SCMM 
data  is  saved  to  a  separate 
Excel  file. 

1.4.2 

User  Query  Response 

The  system  shall 
respond  to  a  user’s 
query  within  xxx 
seconds. 

Test  and  verify  SCMM 
responds  to  a  user’s 
query  within  xxx 
seconds. 

1.4.3 

Simultaneous  Users 

The  system  shall  be 
able  to  handle  xxx 
simultaneous  users. 

Test  and  verify  SCMM  is 
able  to  handle  xxx 
simultaneous  users. 

1.4.4 

Transaction  Rate 

Ability 

The  system  shall  be 
able  to  handle  xxx 
transactions  per 
minute. 

Test  and  verify  SCMM  is 
able  to  handle  xxx 
transactions  per  minute. 

2 

SCMM  System 
Nonfunctional 

Sub-requirements  will  be 
tested. 

2.1 

Technology  & 

Suitability 

Requirements 

Will  not  be  tested. 

2.1.1 

Standards  and 

Protocols 

The  system  shall  meet 
DOD  and  DoN  laws 
and  regulations. 

Will  not  be  tested. 

Requires  full  DOD  and 
DoN  laws  and 
regulations. 

2.1. 1.1 

System  Security 

Will  not  be  tested. 

2.2 

Suitability 

Requirements 

The  system  shall  be 
suitable  for  the  user. 

Sub-requirements  will  be 
tested. 

2.2.1 

Maintainability 

The  system  shall  be 
maintainable. 

TBD 

2.2.1. 1 

Software 

Maintainability 

The  system  shall  be 
able  to  receive 
software  patches  as 
required. 

TBD 
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Requirement 

Description 

Testing  Approach 

2.2.2 

Reliability 

The  system  shall  be 
reliable  with  a  MTBF 
of  xxxxxxx  hours. 

TBD 

2.2.3 

Availability 

The  system  shall  have 
an  Ao  of  90%. 

TBD 

2.2.4 

System  Usability: 
Human  Systems 
Integration  (HSI) 

TBD 

TBD 

2.2.5 

System  Survivability 

TBD 

TBD 

2.2.6 

System  Testability 

TBD 

TBD 

2.2.7 

System  Adaptability 

TBD 

TBD 

Table  14.  Test  Measures  and  Metrics 


B.  TEST  RESULTS  REPORT 

The  test  results  report  details  the  results  of  the  level  1  and  level  2  testing  that  was 
conducted  on  the  SCMM  Excel  simulation.  This  testing  report  provided  feedback  to  the 
SCMM  capstone  team  on  whether  the  system  met  the  requirements  as  defined.  This 
feedback  included: 

•  Test  Pass/Fail  status:  Status  of  all  the  measures  and  metrics  and  whether 
the  tests  for  such  passed  or  failed  were  recorded. 

•  Errors  or  defects:  All  errors  or  defects  found  during  the  testing  were 
identified  and  recorded. 

•  Diversions  from  the  test  scenarios:  Any  additional  diversions  or  issues 
discovered  were  recorded  as  part  of  the  testing  report  and  summary. 

Item  pass/fail  criteria  was  based  on  test  scenarios  and  documented  as  required. 
Suspension  would  only  occur  if  the  simulated  SCMM  system  was  not  ready  for  testing. 
Testing  would  resume  upon  the  availability  of  the  simulated  SCMM  system.  The  test 
results  report  ensues. 


Test  Title: 

Program  File  Name: 
Version  Number: 
Date: 

Tester: 


SCMM  Eevel  1  and  Eevel  2  Testing  for  Excel  Model 
SCMM_Excel_Model_l  .O.xlsm 
1.0 

03  December  2013 
Team  RSRP  Member 
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Estimated  Test  Time: 
Test  &  Support 
Equipment: 

General  Notes: 


30  minutes 

PC  (Desktop  or  Eaptop)  capable  of  running  MS  Excel 
MS  Excel  Version  2007  or  above. 

Timer 

Interoperability  requirements  are  not  tested  per  Test  and 
Verification  Plan. 


Test  Procedure 


Expected  Actual  Pass  / 

Step  Instructions  Results  Results  Pail 

1  Test  loading  of  program. 

NOTE:  Exact  process  for  step  1.1.1  may  vary  depending  on  version  of  MS  Excel  in  use. 
Ensure  Macros  are  allowed. 


1.1 

Open  MS  Excel  program. 

- 

- 

- 

1.1.1 

Select  PIPE,  then  OPEN,  then  select 
the  location  of  the  file  to  be  tested  and 
the  file  to  be  tested. 

- 

- 

- 

1.1.2 

Verify  Excel  file  loads. 

- 

- 

Pass 

2 

Testing  user  inputs. 

- 

- 

- 

2.1 

Select  worksheet 

“User  Input.” 

- 

- 

- 

2.2 

In  cell  Al,  select 

“ECS  I.” 

- 

- 

- 

2.3 

Verify  “ECS  1” 
Al. 

is  displayed  in  cell 

- 

- 

Pass 

2.4 

In  cell  Al,  select 

“ECS  2.” 

- 

- 

- 

2.5 

Verify  “ECS  2” 
Al. 

is  displayed  in  cell 

- 

- 

Pass 

2.6 

In  cell  Al,  select 

“ECS  3.” 

- 

- 

_ 
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Step 

Instructions 

Expected 

Results 

Actual 

Results 

Pass  / 
Fail 

2.7 

Verify  “LCS  3”  is  displayed  in  cell 
Al. 

- 

- 

Pass 

2.8 

In  cell  A2,  select  “Mine  Sweeping.” 

- 

- 

- 

2.9 

Verify  “Mine  Sweeping”  is  displayed 
in  cell  A2. 

- 

- 

Pass 

2.10 

In  cell  A2,  select  “SUW.” 

- 

- 

- 

2.11 

Verify  “SUW”  is  displayed  in  cell  A2. 

- 

- 

Pass 

2.12 

In  cell  A2,  select  “AAW.” 

- 

- 

- 

2.13 

Verify  “AAW”  is  displayed  in  cell  A2. 

- 

- 

Pass 

2.14 

In  cell  A3,  select  “Pacific.” 

- 

- 

- 

2.15 

Verify  “Pacific”  is  displayed  in  cell 
A3. 

- 

- 

Pass 

2.16 

In  cell  A3,  select  “Atlantic.” 

- 

- 

- 

2.17 

Verify  “Atlantic”  is  displayed  in  cell 
A3. 

- 

- 

Pass 

2.18 

In  cell  A3,  select  “Indian.” 

- 

- 

- 

2.20 

Verify  “Indian”  is  displayed  in  cell 
A3. 

- 

- 

Pass 

2.21 

In  cell  A3,  select  “Arctic.” 

- 

- 

- 

2.22 

Verify  “Arctic”  is  displayed  in  cell 
A3. 

- 

- 

Pass 

2.23 

In  cell  A4,  input  “01.” 

- 

- 

- 

2.24 

Verify  “1”  is  displayed  in  cell  A4. 

- 

- 

Pass 

2.25 

In  cell  A4,  input  “123456789.” 

- 

- 

- 
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2.26  Verify  “123456789”  is  displayed  in 

cell  A4. 

2.27  In  cell  A4,  input  “a.” 

2.28  Verify  “a”  is  displayed  in  cell  A4. 

3  Test  system  output. 


Pass 


Pass 


Step  Instructions 

3.1  Input/select  the  following  into  sheet 
“User  Input:” 

(Cell  Al)  Ship:  LCS  1 

(Cell  A2)  Mission:  Mine  Sweeping 

(Cell  A3)  Location:  Pacific 

(Cell  A4)  Mission  Length  (days):  100 

3.2  Select  “Generate  Report”  button. 

3.3  Verify  sheet  changes  to  “Output 
Report.” 

3.4  Verify  displayed  data  for  columns  A 
through  I. 

4  Test  requirements. 

4. 1  Test  input  requirements. 

4.1.1  Verify  the  program  allows  input  of  the 
ship  hull  number. 

4.1.2  Verify  the  program  allows  input  of  the 
ship  seaframe  system. 

4.1.3  Verify  the  program  allows  the  input  of 
multiple  ship  seaframe  systems. 

4.1.4  Verify  the  program  allows  input  of  the 
ship  missile  module  systems. 


Expected 

Results 


Actual 

Results 


Pass  / 

Fail 


Pass 


Pass 


Pass 


Pass 


Fail 


Pass 
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Fail 


4.1.5  Verify  the  program  allows  input  of 
multiple  ship  mission  module  systems. 

4.1.6  Verify  the  program  allows  input  of  the  -  -  Pass 

ship’s  dimensions  for  available  space. 

4.1.7  Verify  the  program  allows  input  of  the  -  -  Fail 

ship’s  available  weight  allowance. 

4.1.8  Verify  the  program  allows  input  of  the  -  -  Fail 

ship’s  availability  requirement. 

4.2  Test  output  requirements.  -  -  - 


Expected  Actual  Pass  / 

Step  Instructions  Results  Results  Fail 

4.2.1  Input/select  the  following  into  sheet  -  -  - 

“User  Input:” 

(Cell  Al)  Ship:  ECS  1 

(Cell  A2)  Mission:  Mine  Sweeping 

(Cell  A3)  Eocation:  Pacific 

(Cell  A4)  Mission  Eength  (days):  100 

4.2.2  Select  “Generate  Report”  button.  -  -  - 


4.2.3  Verify  program  provides  a  report  out  -  -  Pass 

of  the  output  data. 

4.2.4  Verify  the  output  report  displays  the  -  -  Pass 

spares  allocation  on  the  ship. 

4.2.5  Verify  the  output  report  displays  the  -  -  Pail 

spares  allocation  in  the  mission 

modules. 

4.2.6  Verify  the  output  report  displays  the  -  -  Pail 

spares  allocation  at  land-based 

maintenance  facilities. 
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4.2.7 

Verify  the  output  report  displays  the 
spares  allocation  at  MPSF  facilities. 

Fail 

4.2.8 

Verify  the  output  report  displays  the 
spares  allocation  at  OCONUS 
warehouse  facilities. 

- 

- 

Fail 

4.2.9 

Verify  the  output  report  displays  the 
spares  allocation  at  homeport 
allocations. 

- 

- 

Fail 

4.2.10 

Verify  the  output  report  displays  a 
summary  of  all  spare  models. 

- 

- 

Fail 

4.3 

Test  system  functionality 

requirements. 

- 

- 

- 

4.3.1 

Input/select  the  following  into  sheet 
“User  Input:” 

(Cell  Al)  Ship:  LCS  1 

(Cell  A2)  Mission:  Mine  Sweeping 

(Cell  A3)  Location:  Pacific 

(Cell  A4)  Mission  Length  (days):  100 

4.3.2 

Select  “Generate  Report”  button  and 
note  the  time  it  takes  the  program  to 
provide  a  report  out  of  the  output  data 
using  the  timer. 

Expected 

Actual 

Pass , 

Step 

Instructions 

Results 

Results 

Fail 

4.3.3 

Verify  the  program  provides  a  report 
out  of  the  output  data  within  xxx 
seconds 

xxx  seconds 

- 

4.3.4 

Verify  the  program  able  to  handle  xxx 
simultaneous  users. 

xxx  users 

- 

4.3.5 

Verify  the  program  able  to  handle  xxx 
transactions  per  minute. 

xxx 

transactions/min 

- 

214 


4.3.6  Verify  the  program  save  the  output  -  -  Fail 

report  to  a  separate  Excel  file. 

5  Test  complete. 

5.1  Close  program. 


Additional  Comments,  Issues,  or  Notes: 


Step 

Comments,  Issues,  or  Notes 

Test  Tailed 

4.1. 1-4.1. 8 

Data  can  be  inputted  via  the  tables  in  the  program,  which  simulates 
collected  data  from  sources,  versus  being  able  to  be  inputted  by  the  user. 
Requirements  do  not  specify. 

4.2.5- 

4.2.10 

Current  model  does  not  take  into  consideration  other  facilities,  like  MPSE 
or  OCONUS  warehouses. 

4.3.3-4.3.5 

Unable  to  verify  until  requirements  are  further  defined. 

4.3.6 

Able  to  save  Excel  file,  but  not  the  output  report  to  a  separate  Excel  file. 

C.  CONFIGURATION  MANAGEMENT  AND  CHANGE  CONTROL 

Prior  to  testing,  the  system  simulation  was  assigned  the  appropriate  change 
control  /  revision  number.  After  that  point,  any  changes  to  the  SCMM  Excel  simulation 
spreadsheet  or  SCMM  ExtendSim  simulation  spreadsheet  would  require  a  notification  of 
changes  and  a  new  revision  number.  Changes  were  not  made  during  testing  without  prior 
notification  and  appropriate  change  control.  Eigure  88  and  Eigure  89  display  the 
configuration  management  change  tracking  lists  for  the  SCMM  Excel  simulation  and  the 
SCMM  ExtendSim  simulation,  respectively. 
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Version 

File  Name 

Changes  /  Notes 

Date 

1.0 

S  C  M  M Ex  ce  1 M  0  d  e  1 1 . 0 .  X 1  s  m 

Initial 

1/15/2014 

Figure  88.  Configuration  Management  Change  Tracking  List  for  SCMM  Excel 

Simulation 


SCMM  ExtendSim  Model 

Version 

File  Name 

Changes  /  Notes 

Date 

Figure  89.  Configuration  Management  Change  Tracking  List  for  SCMM  ExtendSim 

Simulation 
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APPENDIX  F.  COSYSMO  FACTORS 


Table  15  lists  the  COSYSMO  factors  and  the  prime  motives  for  the  assumptions. 
The  factor  descriptions  are  from  Ricardo  Valerdi. 


COSYSMO 

Factor 

Factor  Description 

System 

Eactor 

Description  / 
Assumption 

Number  of 
System 
Requirements 

“This  driver  represents 
the  number  of 
requirements  for  the 
system-of-interest  at  a 
specific  level  of  design 
(Valerdi  2005,  77). 

OSRAP 

50  Easy, 
25 

Nominal, 

25 

Difficult 

OSRAP  is  a  mature 
system  that  already 
meets  a  number  of 
the  SCMM  system 
requirements. 

ME¬ 

RES 

55  Easy, 
30 

Nominal, 

30 

Difficult 

ME-RES  is  a 
mature  system  that 
already  meets  a 
number  of  the 
SCMM  system 
requirements. 

SCMM 

(Full 

Dev) 

100  Easy, 
50 

Nominal, 

50 

Difficult 

Starting  from  an 
initial  state  with  all 
requirements  to 
complete. 

SCMM 

(Partial 

Dev) 

75  Easy, 
40 

Nominal, 

40 

Difficult 

Able  to  reduce  some 
of  the  requirements 
with  the  use  of  ME¬ 
RES. 

Number  of 
System 
Interfaces 

“This  driver  represents 
the  number  of  shared 
physical  and  logical 
boundaries  between 
system  components  or 
functions  (internal 
interfaces)  and  those 
external  to  the  system 
(external  interfaces)” 
(Valerdi  2005,  83). 

OSRAP 

0  Easy,  3 
Nominal, 

0 

Difficult 

Several  of  the 
expected  system 
interfaces  have 
already  been 
completed. 

ME¬ 

RES 

0  Easy,  3 
Nominal, 

0 

Difficult 

Several  of  the 
expected  system 
interfaces  have 
already  been 
completed. 

SCMM 

(Eull 

Dev) 

0  Easy,  7 
Nominal, 

0 

Difficult 

No  system 
interfaces  in  place. 
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COSYSMO 

Factor 

Factor  Description 

System 

Eactor 

Description  / 
Assumption 

SCMM 

(Partial 

Dev) 

0  Easy,  5 
Nominal, 

0 

Difficult 

Some  of  the 
expected  system 
interfaces  have 
already  been 
completed. 

Number  of 
System- 
Specific 
Algorithms 

“This  driver  represents 
the  number  of  newly 
defined  or  significantly 
altered  functions  that 
require  unique 
mathematical  algorithms 
to  be  derived  in  order  to 
achieve  the  system 
performance 
requirements”  (Valerdi 
2005,  84). 

OSRAP 

0  Easy,  1 
Nominal, 

0 

Difficult 

Several  of  the 
expected  system- 
specific  algorithms 
have  already  been 
completed. 

ME¬ 

RES 

0  Easy,  1 
Nominal, 

0 

Difficult 

Several  of  the 
expected  system- 
specific  algorithms 
have  already  been 
completed. 

SCMM 

(Full 

Dev) 

0  Easy,  4 
Nominal, 

0 

Difficult 

None  of  system- 
specific  algorithms. 

SCMM 

(Partial 

Dev) 

0  Easy,  2 
Nominal, 

0 

Difficult 

Some  of  the 
expected  system- 
specific  algorithms 
have  already  been 
completed. 

Number  of 

Operation 

Scenarios 

“This  driver  represents 
the  number  of  operational 
scenarios  that  a  system 
must  satisfy”  (Valerdi 
2005,  89). 

OSRAP 

0  Easy,  0 
Nominal, 

0 

Difficult 

ME¬ 

RES 

0  Easy,  0 
Nominal, 

0 

Difficult 

SCMM 

(Eull 

Dev) 

0  Easy,  0 
Nominal, 

0 

Difficult 

SCMM 

(Partial 

Dev) 

0  Easy,  0 
Nominal, 

0 

Difficult 

Requirements 

Understanding 

“This  cost  driver  rates  the 
level  of  understanding  of 

OSRAP 

Nominal 

Some  undefined 
areas  exist. 
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COSYSMO 

Factor 

Factor  Description 

System 

Eactor 

Description  / 
Assumption 

the  system  requirements 
by  all  stakeholders 
including  systems, 
software,  hardware, 
customers,  team 
members,  users,  etc.” 
(Valerdi  2005,  98). 

ME¬ 

RES 

Nominal 

Some  undefined 
areas  exist. 

SCMM 

(Full 

Dev) 

Nominal 

Some  undefined 
areas  exist. 

SCMM 

(Partial 

Dev) 

Nominal 

Some  undefined 
areas  exist. 

Architecture 

Understanding 

“This  cost  driver  rates  the 
relative  difficulty  of 
determining  and 
managing  the  system 
architecture  in  terms  of 
platforms,  standards, 
components 

(COTS/GOTS/NDFnew), 
connectors  (protocols), 
and  constraints”  (Valerdi 
2005,  98). 

OSRAP 

Nominal 

Reasonable 
understanding  of 
architecture  and 
COTS  with  some 
unfamiliar  areas. 

ME¬ 

RES 

Nominal 

Reasonable 
understanding  of 
architecture  and 
COTS  with  some 
unfamiliar  areas. 

SCMM 

(Eull 

Dev) 

Nominal 

Reasonable 
understanding  of 
architecture  and 
COTS  with  some 
unfamiliar  areas. 

SCMM 

(Partial 

Dev) 

Nominal 

Reasonable 
understanding  of 
architecture  and 
COTS  with  some 
unfamiliar  areas. 

Level  of 
Service 
Requirements 

“This  cost  driver  rates  the 
difficulty  and  criticality 
of  satisfying  the 
ensemble  of  level  of 
service  requirements, 
such  as  security,  safety, 
response  time, 
interoperability, 
maintainability.  Key 
Performance  Parameters 
(KPPs),  the  “ilities,”  etc.” 
(Valerdi  2005,  101). 

OSRAP 

Nominal 

Moderately 
complex  level  of 
service 
requirements. 

ME¬ 

RES 

Nominal 

Moderately 
complex  level  of 
service 
requirements. 

SCMM 

(Eull 

Dev) 

Nominal 

Moderately 
complex  level  of 
service 
requirements. 
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COSYSMO 

Factor 

Factor  Description 

System 

Eactor 

Description  / 
Assumption 

SCMM 

(Partial 

Dev) 

Nominal 

Moderately 
complex  level  of 
service 
requirements. 

Migration 

Complexity 

“This  cost  driver  rates  the 
extent  to  which  the 
legacy  system  affects  the 
migration  complexity,  if 
any”  (Valerdi  2005,  107). 

OSRAP 

Very 

High 

Different  and 
outside  contractor 
requiring  integration 
and  development. 

ME¬ 

RES 

Very 

High 

Different  and 
outside  contractor 
requiring  integration 
and  development. 

SCMM 

(Eull 

Dev) 

Nominal 

Everything  is  new 
without  any  legacy 
system  in  place. 

SCMM 

(Partial 

Dev) 

High 

Some  use  of 
development  team 
with  some  legacy 
system  in  place. 

Technology 

Risk 

“The  maturity,  readiness, 
and  obsolescence  of  the 
technology  being 
implemented.  Immature 
or  obsolescent 
technology  will  require 
more  Systems 
Engineering  effort” 
(Valerdi  2005,  102). 

OSRAP 

Eow 

Proven  through 
actual  use  and 
available  for 
adoption. 

ME¬ 

RES 

Eow 

Proven  through 
actual  use  and 
available  for 
adoption. 

SCMM 

(Eull 

Dev) 

Very 

High 

Still  in 

development. 

SCMM 

(Partial 

Dev) 

High 

Still  in  development 
but  based  on  some 
actual  use. 

Documentation 

The  formality  and  detail 
of  documentation 
required  to  be  formally 
delivered  based  on  the 
life  cycle  needs  of  the 
system  (Valerdi  2005, 
104). 

OSRAP 

Nominal 

Consistent  levels  of 
documentation 
required. 

ME¬ 

RES 

Nominal 

Consistent  levels  of 
documentation 
required. 

SCMM 

(Eull 

Dev) 

Nominal 

Consistent  levels  of 
documentation 
required. 
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COSYSMO 

Factor 

Factor  Description 

System 

Eactor 

Description  / 
Assumption 

SCMM 

(Partial 

Dev) 

Nominal 

Consistent  levels  of 
documentation 
required. 

Number  of 
Installs/ 
Platforms 

“The  number  of  different 
platforms  that  the  system 
will  be  hosted  and 
installed  on.  The 
complexity  in  the 
operating  environment 
(space,  sea,  land,  fixed, 
mobile,  portable, 
information 
assurance/security, 
constraints  on  size 
weight,  and  power)” 
(Valerdi  2005,  105). 

OSRAP 

Nominal 

Only  a  single 
installation  and 
configuration  is 
required. 

ME¬ 

RES 

Nominal 

Only  a  single 
installation  and 
configuration  is 
required. 

SCMM 

(Eull 

Dev) 

Nominal 

Only  a  single 
installation  and 
configuration  is 
required. 

SCMM 

(Partial 

Dev) 

Nominal 

Only  a  single 
installation  and 
configuration  is 
required. 

Number  of 
Recursive 
Levels 

“The  number  of  levels  of 
design  related  to  the 
system-of-interest  (as 
defined  by  ISO/IEC 
15288)  and  the  amount  of 
required  SE  effort  for 
each  level”  (Valerdi 
2005,  103). 

OSRAP 

Nominal 

Required  SE  effort 
is  based  on  more 
complex 

interdependencies 
and  tradeoffs. 

ME¬ 

RES 

Nominal 

Required  SE  effort 
is  based  on  more 
complex 

interdependencies 
and  tradeoffs. 

SCMM 

(Eull 

Dev) 

Nominal 

Required  SE  effort 
is  based  on  more 
complex 

interdependencies 
and  tradeoffs. 

SCMM 

(Partial 

Dev) 

Nominal 

Required  SE  effort 
is  based  on  more 
complex 

interdependencies 
and  tradeoffs. 

Stakeholder 
Team  Cohesion 

“Represents  a  multi¬ 
attribute  parameter  which 
includes  leadership, 
shared  vision,  diversity 

OSRAP 

High 

Well  established 
program  with  clear 
rules  and 
responsibilities. 
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COSYSMO 

Factor 

Factor  Description 

System 

Factor 

Description  / 
Assumption 

of  stakeholders,  approval 
cycles,  group  dynamics. 
Integrated  Product  Team 
framework,  team 
dynamics,  trust,  and 
amount  of  change  in 
responsibilities”  (Valerdi 
2005,  99). 

ME¬ 

RES 

High 

Well  established 
program  with  clear 
rules  and 
responsibilities. 

SCMM 

(Full 

Dev) 

Eow 

Heterogeneous 
community  with 
converging 
organizational 
objectives. 

SCMM 

(Partial 

Dev) 

Eow 

Heterogeneous 
community  with 
converging 
organizational 
objectives. 

Personnel  / 
Team 
Capability 

“Composite  intellectual 
capability  of  a  team  of 
Systems  Engineers 
(compared  to  the  national 
pool  of  SEs)  to  analyze 
complex  problems  and 
synthesize  solutions” 
(Valerdi  2005,  107). 

OSRAP 

Nominal 

Standard  capability. 

ME¬ 

RES 

Nominal 

Standard  capability. 

SCMM 

(Full 

Dev) 

Nominal 

Standard  capability. 

SCMM 

(Partial 

Dev) 

Nominal 

Standard  capability. 

Personnel 

Experience/ 

Continuity 

“The  applicability  and 
consistency  of  the  staff  at 
the  initial  stage  of  the 
project  with  respect  to 
the  domain,  customer, 
user,  technology,  tools, 
etc.”  (Valerdi  2005,  100). 

OSRAP 

High 

Several  years  of 
experience. 

ME¬ 

RES 

High 

Several  years  of 
experience. 

SCMM 

(Full 

Dev) 

Eow 

Few  years  of 
experience. 

SCMM 

(Partial 

Dev) 

Eow 

Few  years  of 
experience. 

Process 

Capability 

“The  consistency  and 
effectiveness  of  the 
project  team  at 
performing  SE 
processes”  (Valerdi  2005, 
108). 

OSRAP 

Nominal 

Standard 
consistency  and 
effectiveness  of 

team. 

ME¬ 

RES 

Nominal 

Standard 
consistency  and 
effectiveness  of 

team. 
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COSYSMO 

Factor 

Factor  Description 

System 

Eactor 

Description  / 
Assumption 

SCMM 

(Full 

Dev) 

Nominal 

Standard 
consistency  and 
effectiveness  of 

team. 

SCMM 

(Partial 

Dev) 

Nominal 

Standard 
consistency  and 
effectiveness  of 

team. 

Multisite 

Coordination 

“Location  of 
stakeholders,  team 
members,  resources, 
corporate  collaboration 
barriers”  (Valerdi  2005, 
109). 

OSRAP 

Nominal 

Some  coordinated 
teams  and 

resources. 

ME¬ 

RES 

Nominal 

Some  coordinated 
teams  and 

resources. 

SCMM 

(Eull 

Dev) 

Very 

High 

Coordinated  teams 
and  resources. 

SCMM 

(Partial 

Dev) 

High 

Mostly  coordinated 
teams  and 

resources. 

Tool  Support 

“Coverage,  integration, 
and  maturity  of  the  tools 
in  the  Systems 
Engineering 
environment”  (Valerdi 
2005,  110). 

OSRAP 

Very 

High 

Strong  and  mature 
use  of  SE  tools. 

ME¬ 

RES 

Very 

High 

Strong  and  mature 
use  of  SE  tools. 

SCMM 

(Eull 

Dev) 

Very 

High 

Strong  and  mature 
use  of  SE  tools. 

SCMM 

(Partial 

Dev) 

Very 

High 

Strong  and  mature 
use  of  SE  tools. 

System  Labor 
Rates 

Cost  per  Person-Month 

OSRAP 

$10,000 

Standard  Costs 

ME¬ 

RES 

$10,000 

Standard  Costs 

SCMM 

(Eull 

Dev) 

$10,000 

Standard  Costs 

SCMM 

(Partial 

Dev) 

$10,000 

Standard  Costs 

Table  15.  COSYSMO  Factors  Defined  for  the  SCMM  System 
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APPENDIX  G.  SUPPLY  CHAIN  MANAGEMENT  MODEL  RISK 

MANAGEMENT  PLAN 


Risk  management  addresses  the  processes  for  identifying,  assessing,  mitigating, 
and  monitoring  the  risks  expected  or  encountered  during  a  project’s  life  cycle.  The  risk 
management  process  used  by  the  team  was  based  on  the  following  principles  defined  in 
the  Risk  Management  Guide  for  DOD  Acquisition,  the  sixth  edition:  “risk  identification, 
risk  analysis,  risk  mitigation  planning,  risk  mitigation  plan  implementation,  and  risk 
tracking”  (Department  of  Defense  2006,  4).  Risk  Management  takes  a  proactive  and  well- 
planned  role  in  anticipating  problems  and  responding  to  them  if  they  occur  (Department 
of  Defense  2006).  Therefore,  when  conducting  risk  management,  the  goal  is  to  employ  a 
methodology  that  can  be  continuously  used  to  identify,  analyze,  mitigate,  and  track  risk 
(Department  of  Defense  2006).  The  team  accomplished  this  using  the  process  identified 
in  the  Risk  Management  Guide  for  DOD  Acquisition,  the  sixth  edition;  see  Figure  90. 


Risk 

Mitigation 

Plan  Implementation 


Figure  90.  DOD  Risk  Management  Process  (from  Department  of  Defense  2006,  4) 
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The  roles  and  responsibilities  of  the  team  as  it  relates  to  risk  management 
planning  are  identified  in  Table  16.  This  served  as  a  guideline  for  how  the  team 
conducted  risk  management  throughout  the  project. 


Category 

Responsible  Role(s) 

Responsibility 

Program 

Management 

Risk 

Project  Team  Lead, 
Scheduler,  Product 
Accountability  Area 
(PAA)  Leads 

Iteratively  review  the  programmatic  goals 
and  objectives  for  progress  by  utilizing  the 
Master  Schedule,  Stakeholder 

Expectations,  and  any  other  metrics 
necessary  to  determine  risks  within 

Program  Management  and  provide  input  to 
the  Risk  Assessors. 

Technical 

Risk 

PAA  Leads 

Iteratively  review  the  technical  goals  and 
objectives  for  progress  by  utilizing  the 
Master  Schedule,  Stakeholder 

Expectations,  and  any  other  metrics 
necessary  to  determine  risks  within  the 
technical  execution  and  provide  input  to 
the  Risk  Assessors. 

Overall 

Program 

Risk 

Cost  &  Risk  Analysis 
PAA 

Responsible  for  advising  of  any  potential 
risks  by  identifying  issues,  developing  a 
mitigation  strategy  or  plans,  and 
determining  if  a  risk  should  be  assumed, 
avoided,  reduced,  or  transferred 

Table  16.  Risk  Management  Responsibilities  (after  Team  Liberty  311-1 14G  2012) 


A.  RISK  IDENTIFICATION  AND  ANALYSIS 

The  team  identified  risks  throughout  the  project  lifecycle.  Table  17  details 
potential  risk  the  team  could  have  encountered  during  the  capstone  project.  From  this 
analysis,  the  team  identified  and  grouped  the  risks  into  three  areas:  technical,  program 
management,  and  overall  program. 
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Project  Proposal 

Preliminary  Project 
Planning 

Project  Execution 

Project  Closure 

Subject  matter 
experts  not 
available 

No  risk 

management  plan 

Information 

availability 

Unacceptable  to 
customer 

Poor  problem 
definition 

Hasty  planning 

Personnel 

availability/workload 

Unclear  objectives 

Poor  role  definition 

Scope  changes 

Inexperienced  team 

Technical  problems 

Table  17.  Capstone  Project  Lifecycle  Risk  Analysis 


Each  product  accountability  area  (PAA)  lead  provided  periodic  updates  to  the  cost 
and  risk  analysis  PAA  and  the  team  lead.  The  cost  and  risk  analysis  PAA  would  then  take 
the  identified  risks  and  document  them  in  a  Microsoft  Excel  spreadsheet  to  track  the 
project’s  risks.  This  spreadsheet  assigned  each  risk  a  number,  identified  the  risk  area, 
provided  details  of  the  risk,  showed  the  current  likelihood  and  consequence  and  identified 
the  risk  mitigation  strategy.  The  team  tracked  both  project  and  system  risks  in  the  Risk 
Management  Spreadsheet.  The  team  classified  each  risk  into  the  following  two 
categories:  system  risk  and  project  risk.  A  system  risk  is  directly  related  to  the  technical 
aspects  of  the  supply  chain  management  model  (SCMM);  while  a  project  risk  is  directly 
related  to  the  team’s  ability  to  complete  the  capstone  project.  As  risks  were  successfully 
mitigated,  the  risks  would  be  retired  and  moved  to  a  different  tab  of  the  spreadsheet.  This 
provided  the  team  with  a  current  listing  of  the  “open”  project  and  system  risks.  A  sample 
of  this  spreadsheet  can  be  seen  in  Table  18  and  Table  19.  Table  18  shows  the  spreadsheet 
for  the  team’s  project  risks.  The  three  project  risks  that  had  been  closed  by  the  team  are 
not  listed,  which  is  why  Table  18  does  not  show  risk  numbers  2,  3,  or  6.  Table  19  shows 
the  spreadsheet  for  the  team’s  system  risks.  There  also  is  one  system  risk  that  was  closed, 
which  is  why  there  is  no  risk  number  2  in  Table  19. 
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Risk  Management  Status — Project  Risks 

Risk 

No. 

Risk  Area 

Narrative 

Likeli¬ 

hood 

Consequence 

Mitigation 

Strategy 

1 

Technical 

Risk 

S  akai/Elluminate 
server  issues. 

3 

2 

Risk  will  be 
assumed  by 
having  multiple 
meetings.  Telcons 
and  physical 
meetings  are  also 
options. 

4 

Program 

Management 

Planned/Unplanned 
team  member 
absences. 

5 

1 

Planned  absences 
will  be 

documented  on 
the  Sakai 
calendar. 

Unplanned 
absences  will  be 
assumed  by 
available  team 
members. 

Overall 

Program 

Risk 


Balancing  Capstone 
project  with  other 
workload. 


Overall 

Program 

Risk 


Requirements  too 
vague. 


Overall 

Program 

Risk 


Requirements 
developed  without 
defined  problem 
statement. 


Risk  will  be 
reduced  by  having 
backups  and  co¬ 
leads  for  the 
various  meetings 
and  PA  As. 


Risk  will  be 
avoided  by 
making 
requirements 
more  specific 
based  on  feedback 
from  the  sponsor 
and  refinement  of 
the  problem 
statement. 


Risk  will  be 
avoided  by 
refining  problem 
statement  and 
revising 
requirement. 
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Risk  Management  Status — Project  Risks 

Risk 

No. 

Risk  Area 

Narrative 

Likeli¬ 

hood 

Consequence 

Mitigation 

Strategy 

9 

Overall 

Program 

Risk 

Stakeholder 
feedback  requires 
lengthy  Institutional 
Review  Board 
(IRB)  process. 

1 

4 

Risk  will  be 
avoided  by 
inviting 
stakeholders  to 

IPRs  and  getting 
feedback/question 
s  at  that  time. 

Also,  feedback 
from  sponsor’s 
interactions  with 
stakeholders  will 
be  used. 

10 

Program 

Management 

Schedule  Slip 

2 

5 

Risk  will  be 
avoided  by  the 
team  re-scoping 
our  project  and 
deliverables  to 
complete  the 
Capstone  on  time. 

Table  18.  Cohort  31 1-123L  Risk  Management  Spreadsheet  for  Project  Risk 


Risk  Management  Status — System  Risks 


Risk 

No. 


Risk  Area 


Technical 

Risk 


Overall 

Program 

Risk 


Technical 

Risk 


Narrative 


Interoperability 
with  other 
systems 


Retirement 

Risk 


Operational 

Risks 


Mitigation 
Strategy 
With  other 
databases  and 
software 
systems — Check 
software  interfaces 
in  the  design 
phase  rather  than 
waiting  until 
integration  testing 
Retiring  the 
system  cannot  be 
mitigated. _ 

Training  plan  will 
be  developed  and 
tracked  to  identify 
required  training. 
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Risk  Management  Status — System  Risks 

Risk 

No. 

Risk  Area 

Narrative 

Likelihood 

Consequence 

Mitigation 

Strategy 

5 

Overall 

Program 

Risk 

Implementation 

Risks 

3 

3 

1)  Unrealistic  user 
expectations:  To 
gain  sponsor 
acceptance,  we 
met  several  times 
to  discuss 
implementation 
approach. 

2)  Application 
complexity:  The 
process  model  was 
monitored 
throughout  the 
development 
phase  to  ensure  it 
was  working. 

Table  19.  Cohort  31 1-123L  Risk  Management  Spreadsheet  for  System  Risk 


Once  identified,  the  risks  had  to  be  analyzed  by  the  Cost  and  Risk  Analysis  PAA. 
According  to  the  Department  of  Defense,  “The  objective  of  risk  analysis  is  to  gather 
enough  information  about  future  risks  to  judge  the  root  causes,  the  likelihood,  and 
consequences  if  risk  occurs”  (2006,  14).  The  analysis  was  accomplished  by  examining 
the  risks  that  had  been  previously  identified.  The  examination  “...identified  risks  to 
isolate  the  cause,  determine  the  effects  and  aid  in  the  setting  of  risk  mitigation  priorities” 
(Department  of  Defense  2006,  14).  This  was  done  by  refining  the  “...risk  in  terms  of 
likelihood  and  consequence  to  other  risk  areas”  (Department  of  Defense  2006,  14).  The 
levels  of  likelihood  and  types  of  consequence  of  each  risk  listed  in  the  risk  tracking 
spreadsheet  were  established  utilizing  the  Risk  Management  Guide  for  DOD  Acquisition, 
the  sixth  edition  specified  criteria  in  Table  20  and  Figure  91.  It  should  be  noted  that  the 
team  modified  Figure  91  slightly  to  accommodate  the  timeframe  of  the  capstone  project 
by  changing  the  length  of  time  in  the  schedule  column  from  months  to  weeks. 


230 


Level 

Likelihood 

Probability  of  Occurrence 

1 

Not  Likely 

-10% 

2 

Low  Likelihood 

-30% 

3 

Likely 

-50% 

4 

Highly  Likely 

-70% 

5 

Near  Certainty 

-90% 

Table  20.  Levels  of  Likelihood  Criteria  (from  Department  of  Defense  2006,  12) 


Level 

Technical  Performance 

Schedule 

Overall  Program  Risk 

1 

Minimelor  no  conse<|uenoe  totechnicsl 
performance 

M  i  n  ima  1  or  no  i  mpact 

M  i  n  ima  1  or  n  o  i  mp  act  to 
overall  pro^^am 

2 

M  i  nor  redu  cbo  n  i  n  techn  ica  1  performens  or 
supportability.  can  be  tolerated  wilh  little  or 
no  impact  on  pro^am 

Able  to  meet  key  dates. 

Slip<^week{s) 

Minor 

3 

Moderate  redu dian  intechnical 
performan  ce  or  su  pportab  ility  wi  th  1  imited 
impacton  program  objectives 

Minor  scbeduleslip.  Able  to  meetkey 
milestones  with  noschedule  float 

Slip  <^week(s) 

Sub-system  slip  >^week|s)  plus 
available 

Moderate 

4 

S  ig  n  if  ican  t  de^s  dat  b  n  i  n  te  chnica  1 
performan  ce  or  m  ajor  shortfe  II  i  n 
supportability:  may  Jeopardize  program 
success 

Program  critical  path  affected. 
Slip<^wedr(s) 

Significant 

5 

Severe  de^adatbn  i  n  techni  ca  1 
performan  ce;  Ca  nnot  meet  KPP  or  key 
tech  n  i  ca  Isu  pportabi  \ify  threshob;  wi  II 
Jeopardize  program  su  ccess 

Cannot  meet  key  program  milestones. 
Slip>^we€h{s) 

Severe 

Figure  91.  Types  of  Consequence  Criteria  (after  Department  of  Defense  2006,  13) 


The  information  contained  in  the  risk  tracking  spreadsheet  was  then  plotted  in  a 
risk  reporting  matrix.  This  risk  reporting  matrix  was  used  to  depict  the  level  of  risks 
identified  with  this  project.  The  level  of  risk  for  each  issue  was  reported  as  low  (green), 
moderate  (yellow),  or  high  (red).  A  sample  of  the  Risk  Report  Matrix  is  shown  in  Figure 
92  using  data  from  Table  18  Cohort  31 1-123L  Risk  Management  Spreadsheet  for  Project 
Risk.  In  this  example,  risk  #1,  is  shown  with  a  circle  and  arrow  around  it,  indicating  that 
due  to  the  used  mitigation  strategy  the  likelihood  and  consequence  of  this  risk  has 
decreased. 
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Figure  92.  Risk  Report  Matrix  (after  Department  of  Defense  2006,  11) 


B.  RISK  MITIGATION 

According  to  the  Department  of  Defense,  “Risk  mitigation  is  the  activity  that 
identifies,  evaluates  and  selects  the  best  option  to  set  a  risk  at  an  acceptable  level,  based 
on  project  objectives  and  constraints”  (2006,  33).  Once  a  risk  has  been  identified,  four 
tools  are  used  to  evaluate  and  treat  the  risk:  avoid,  assume,  control,  or  transfer.  Avoiding 
risk  entails  utilizing  an  approach  to  eliminate  the  root  cause  and/or  consequence  of  the 
risk,  therefore  avoiding  the  risk  (Department  of  Defense  2006).  If  a  risk  cannot  be 
avoided  then  it  becomes  an  assumed  risk  that  will  have  to  be  monitored.  Another  tool 
used  in  risk  mitigation  is  controlling  risk.  This  tool  examines  the  root  cause  or 
consequence  of  a  risk  and  uses  mitigation  techniques  to  reduce  the  risk  to  an  acceptable 
level  (Department  of  Defense  2006).  Transferring  risk  transfers  mitigation  of  the  risk  to 
another  organization  or  entity.  The  Cost  and  Risk  Analysis  PAA  utilized  these  tools  in 
mitigating  the  risks  identified  by  the  team  as  the  project  progressed. 
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As  previously  mentioned,  the  team  utilized  the  Risk  Management  Spreadsheet  to 
record  the  type  of  risk,  the  specific  risk/narrative,  as  well  as  the  likelihood,  consequence 
and  risk  mitigation  strategy  for  each  risk.  Table  18  describes  the  mitigation  strategies  for 
the  project  risks.  These  strategies  entailed  the  capstone  team  interacting  with  the  sponsor, 
stakeholders  or  capstone  advisor  to  find  a  way  to  mitigate  the  identified  risks.  The  team 
also  made  decisions  to  cover  schedule  and  absence  risks  to  ensure  the  capstone  project 
was  completed  within  the  established  timeframe.  The  mitigation  strategies  for  the  system 
risks,  shown  in  Table  19,  are  tailored  to  each  individual  risk.  Mitigating  the 
interoperability  risks  focused  on  examining  the  software  interfaces  that  the  SCMM 
system  will  have  with  the  different  databases  it  will  be  receiving  information  from.  In 
order  to  control  this  risk,  the  team  checked  software  interfaces  in  the  design  phase  rather 
than  waiting  until  integration  testing,  to  ensure  interoperability  and  reduce  costs.  The 
concern  about  accessing  classified  information  via  the  SIPRNET  may  be  avoided  by 
determining  whether  the  classified  data  is  really  required  for  the  SCMM,  and  if  so, 
whether  it  can  be  entered  as  an  unclassified  user  input  rather  than  receiving  the 
information  from  the  classified  databases.  The  team  avoided  this  “classified  information 
sharing”  risk,  which  was  system  risk  #2,  and  so  it  is  not  listed  in  the  table.  The  retirement 
risk  is  minimal;  therefore,  there  is  no  mitigation  plan  for  this  risk.  The  operational  risks 
mitigation  strategy  will  be  to  develop  a  training  plan  for  the  SCMM  based  on  the  training 
requirements  for  users  to  operate  the  SCMM.  The  final  system  risk  the  team  identified 
was  implementation  risks.  One  of  these  risks  was  unrealistic  user  expectations.  This  can 
be  mitigated  by  consistently  meeting  with  the  sponsor  to  ensure  the  team’s  efforts  stay  on 
track  and  meet  with  the  sponsor’s  approval.  The  complexity  of  the  SCMM  application  is 
another  implementation  risk.  It  can  be  mitigated  by  continuously  monitoring  the  process 
model  throughout  the  development  process  to  ensure  the  final  product  is  user-friendly.  As 
risks  were  successfully  mitigated,  they  were  retired  from  being  actively  tracked  / 
monitored  by  the  team. 

C.  RISK  TRACKING 

As  previously  discussed,  risk  management  is  an  ongoing  activity  that  will 

continue  throughout  the  life  of  the  project.  This  process  included  the  continued  activities 
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of  risk  identification,  risk  assessment,  planning  for  newly  identified  risks,  monitoring 
trigger  conditions  and  contingency  plans,  and  risk  reporting  on  a  regular  basis.  Tracking 
risks  throughout  the  capstone  was  another  necessary  activity  handled  by  the  Cost  and 
Risk  Analysis  PAA.  This  was  accomplished  utilizing  the  Risk  Management  Spreadsheet; 
see  Table  18  and  Table  19,  during  the  team’s  weekly  project  status  meetings.  During  the 
risk  portion  of  the  status  meeting,  new  risks  were  presented  along  with  status  changes  of 
existing  risks.  Some  risk  attributes,  such  as  likelihood  and  consequence,  changed  during 
the  life  of  this  project  and  these  were  documented  and  presented  as  well. 
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